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(57) A distributed computing environment in which agent processes direct their own movement through a 
W computer network. Place processes provide a computing context within which agent processes are 
interpreted An agent process controls its movement from one place process to another within the 
network by using a ticket. An agent process which moves from one place process to another transports 
definitions of classes of which objects included in the agent process are members. An agent process 
which moves from one place process to a second place process avoids unnecessary transportation of 
objects included in the agent process by substituting equivalent objects which are found in the second 
place process. An agent process sends clones of the agent process to several place processes 
simultaneously. If two clones travel along paths which are coextensive for an initial portion thereof a 
single clone is transported along the initial portion of the paths and other clones are formed from the 
single clone thereby avoiding transferring redundant information along communications media. Two 
agent processes, which occupy a single place process, interact by exchanging references to one 
another The single place process ensures that neither agent process receives a reference to the other 
agent process without simultaneously giving to the other agent process a reference to the former agent 
process. Unauthorized or inadvertent excessive use of network resources by an agent process, or a 
place process, is prevented by associating with each process a permit which defines various capabilities 
and resource allowances of the process. 



Jouve, 18, rue Saint-Denis, 75001 PARIS 



EP 0 634 719 A2 



10 



CROSS REFERENCE TO APPENDIX E, F AND G 

(copies of which have been filed with this application and form part of US application 08/090 521 which 
was filed at the United States Patent Office on 8 July 1993. 

Appendix E, which is incorporated herein by reference, describes the interchange of objects during the 
movement of a process through a network in one embodiment of the present invention, which is described more 
completely below. 

Appendix F, which is incorporated herein by reference, describes the transfer of data between computer 
systems interconnected via a network in one embodiment of the present invention. 

Appendix G, which is incorporated herein by reference, is a list of computer programs and related data in 
one embodiment of the present invention, which is described more completely below. 

A portion of the disclosure of this patent document contains material which is subject to copyright protec- 
tion. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or 
the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise 
15 reserves all copyright rights whatsoever. 

FIELD OF THE INVENTION 

This invention relates to a distributed computing environment and in particular, to an improved distributed 
20 computing environment wherein processes are created in an object oriented environment and direct their own 
movement throughout a computer network. 

BACKGROUND OF THE INVENTION 

Many different computing systems are available today, but most of these systems are built around funda- 
mental components such as those illustrated in Figure 1 . Typically, a computer system 20 includes a central 
processing unit 1 0 (CPU), which is connected through an input bus 11 to an input module 12 and through an 
output bus 13 to an output module 14. CPU 10 is also connected through data buses 15, 16 to a memory unit 

CPU 10 provides control and computing functions. Input and output modules 12, 14 are used to commu- 
nicate between the computer user and CPU 10. Input module 12 supplies information to CPU 10 Typical input 
devices are a keyboard and a mouse. Output module 14 displays information from central processing unit 10 
Typical output modules include video display monitors, printers, plotters and other visual display means. Input 
unit 12 and output unit 14 are frequently referred to as input/output (I/O) units. 

Memory unit 1 7 typically contains two general types of information, instructions and data. A computer pro- 
gram is a sequence of instructions that are executed by the computer to perform a specific function Data in 
memory unit 17 are processed by CPU 10 in response to the instructions from a computer program which is 
executing in CPU 10. An executing computer program is called a computer process. 

Memory unit 17 typically includes mass memory 17A, sometimes called secondary memory and main 
memory 1 7B. Main memory 1 7B is usually used to store at least a portion of a program currently being executed 
by CPU 10 and data required by the program. Mass memory 17A, e.g. magnetic disk or tape, is used to store 
programs, data, or portions of either programs or data which are not needed immediately by CPU 10 or which 
cannot be accommodated in main memory 17B because of size limitations of main memory 17B. 

The operating system of a computer is a computer process which coordinates operation of CPU 10 I/O 
devices 12. U and 17A and main memory 17B and which provides an interface between user applications 
(defined belc - and computer hardware. As is used herein, the term computer hardware refers to the physical 
components or the computer system. As an operating system is necessary for the orderly operation of a com- 
puter system, the operating system is loaded into main memory 1 7B and executed during power up of the com- 
puter system (a process called "booting") and remains in main memory 1 7B and in execution until the computer 
50 system is ultimately deactivated. 

A user application generally refers to a computer process which executes in addition to, and is generally 
considered distinct from, the operating system. A user application begins at some point in time as source code 
i.e.. computer instructions in a form intelligible to human beings. This source code is translated or "compiled" 
into object code, which is a form intelligible to computer system 20, particularly CPU 10. Several object code 
55 modules may be linked to form a single executable image, which is in a form which can be processed by CPU 
10 of computer system 20. The program is executed by copying the executable image into main memory 17B 
and instructing CPU 10 to carry out the instructions, one by one. of the executable image. As stated above 
a computer program in such state of execution is called a process. 
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The instructions executed by a process executing within computer system 20 generally manipulate the re- 
sources of computer system 20. For example, instructions can manipulate data stored in mass memory 17A, 
accept data from input module 12 or display data on output module 14, Some processes, which are designed 
to execute on a first computer system, are configured to issue computer instructions which manipulate resourc- 

5 es of a second computer system. 

It is well-known in the art of computer communications to connect two or more computer systems such 
that data can be transferred between two or more computer systems. Two or more computer systems so con- 
nected are collectively called a "network". In such a network, each computer system treats each other com- 
puter system as an I/O device to which data can be sent and from which data can be received. 

10 A first process executing on a first computer system can issue instructions to a second process executing 

on a second computer system. The second process then manipulates the resources of the second computer 
system in accordance with the instructions received from the first process. The second process is called a 
"server" process because the second process provides a service to the first process, which is called a "client" 
process. The service provided is the manipulation of resources of the second computer system. 

15 Many computer communication systems implement what is called "remote procedure calling". In remote 

procedure calling, a client process, which is executing on a first computer system and which seeks to manip- 
ulate data on a second computer system, requests action through a server process, which is executing on the 
second computer system and which manipulates data in response to requests from the client process. The 
server process performs any of an inevitably finite list of operations on behalf of the client process. Often it is 

20 the case that the precise function requested by the client process is not among the particular operations per- 
formed by the server process. To perform a function for which no server process operation is defined requires 
several requests to and responses from the server process that require substantial use of communications 
media which in turn involves considerable expense and time. 

Logic flow diagram 200 (Figure 2A) illustrates an example of remote procedure calling. Logic flow diagram 

25 200 is described in the context of computer systems 20A and 20B (Figure 2B), which are interconnected through 
network 256. Suppose a client process 252 on computer system 20A is to delete all files on computer system 
20B whose names match a given pattern, e.g., file names ending in ".TMP", and which have not been modified 
in at least 30 days. Client process 252 sends to server process 254 which is executing on computer system 
20B a request to list all files in step 21 (Figure 2A). Arrow 260 (Figure 2B) represents that request. Processing 

30 transfers from step 21 (Figure 2A) to step 22 in which client process 252 (Figure 2B) receives the listfrom 
server process 254. as shown as arrow 262. Steps 21 and 22 (Figure 2A) involve two transfers across network 
communications media. 

Double rectangles in Figures 2A and 3A indicate information transfer across network 256 (Figure- 2B). 
Whereas execution of an instruction within either computer 20A or computer 20B takes between several nano- 

35 seconds to several microseconds, transfer of information across network 256 generally takes seconds or min- 
utes depending on the configuration of network 256 and on the amount of information. In some networks, trans- 
fer of a large amount of data can take an hour or more. 

Processing transfers from step 22 (Figure 2A) to for each filename step 23. For each filename step 23 
and next steps 23a, 23b and 23c define a loop within which each filename of the list of filenames is processed 

40 by the client process. For each filename of the list, processing transfers from for each filename step 23 to a 
test step 24 in which client process 252 (Figure 2B) compares the filename to a pattern. If the filename does 
not match the pattern, processing transfers from test step 24 (Figure 2A) through next step 23a to for each 
filename step 23 and the next filename is processed. 

Conversely, if the filename matches the pattern, processing transfers from test step 24 to step 25. In step 

45 25, client process 252 (Figure 2B) sends to server process 254 an instruction to provide the date that the par- 
ticular file was last modified as shown by arrow 264. Processing transfers from step 25 (Figure 2A) to step 26 
in which client process 252 (Figure 2B) receives from server process 254 the date requested as represented 
by arrow 266. Steps 25 and 26 (Figure 2A) involve two more transfers across network communications media 
for each such matching filename. 

50 Processing transfers from step 26 to a second test step 27 in which client process 252 (Figure 2B) com- 

pares the date received with the current date less 30 days. If the date indicates that the file has been modified 
within the preceding 30 days, processing transfers from second test step 27 (Figure 2A) through next step 23b 
to for each filename test step 23 in which the next filename is processed. Conversely, if the date indicates 
that the file has not been modified within the preceding 30 days, processing transfers from second test step 

55 27 to step 28. 

In step 28, client process 252 (Figure 2B) sends to server process 254 an instruction directing server proc- 
ess 254 to delete the file from computer system 20B as represented by arrow 268. Processing transfers from 
step 28 to step 29 (Figure 2A). in which client process 252 (Figure 2B) receives from server process 254 ac- 
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knowledgement of the deletion as represented by arrow 270. Thus, steps 28 and 29 (Figure 2A) involve two 
further transfers across network 256 (Figure 2B) for each file to be deleted. 

Processing transfers from step 29 through next step 23C to for each filename step 23. If all filenames in 
the list have been processed, processing transfers from for each filename step 23 to terminal step 20b in which 
5 processing terminates. Thus, processing according to logic flow diagram 200 (Figure 2A) requires a multitude 
of information transfers across network 256. Such heavy use of network communications media is both costly 
and time consuming. 

An alternative approach to remote procedure calling is "remote programming". In remote programming, a 
process, which is called a "client process" and which executes on a first computer system, sends to a server 
10 process executing on the second computer system a list of instructions. The instructions are then carried out 
by the server process effectuating the goal of the client process. The instructions which the server process 
is designed to carry out must have some degree of generality; i.e., the instructions must provide some degree 
of decision-making capabilities. 

Logic flow diagram 300 (Figure 3A) illustrates an example of remote programming. To effectuate the ex- 
15 ample given above with respect to Figures 2A and 2B in a remote programming environment, client process 
352 (Figure 3B) in step 31 (Figure 3A) builds a program whose instructions are represented by logic flow di- 
agram 31 -P. Logic flow diagram 31 -P is described below. 

Processing transfers from step 31 to step 32. in which the program is transferred to computer 30B (Figure 
3B) through network 356 as represented by arrow 358. Processing transfers from step 32 to step 33 (Figure 
20 3A) in which the program is executed within computer 30B. During execution, the program is process 352A 
(Figure 3B) within computer 30B. The instructions of program 352A are executed according to logic flow dia- 
gram 300. 

In step 31-B (Figure 3A), a list of filenames is created. Processing transfers from step 31-B to for each 
filename step 31-C. For each filename step 31 -C and next steps 31-H, 31-1, and 31-J form a loop within which 

25 each filename in the list of filenames is processed. For each filename, processing transfers from for each fi- 
lename step 31-C to test step 31-D in which the filename is compared to a pattern. If the filename does not 
match the pattern, processing transfers from test step 31-D through next step 31-H to for each step 31-C. Con- 
versely, if the filename matches the pattern, processing transfers from test step 31-D to step 31 -E. 

In step 31-E, process 352A retrieves the date of last modification of the file having the filename, Proc- 

30 essing transfers from step 31-E to a second test step 31 -F in which the date is compared to the current date 
less 30 days. The date of last modification of the file is retrieved from server process 354 (Figure 3B). If the 
date of last modification is more recent than the date of 30 days prior, processing transfers from second test 
step 31-F (Figure 3A) through next step 31-1 to for each filename step 31-C. Conversely, if the date of last 
modification is prior to the date of 30 days prior, processing transfers from second test step 31-F to step 31- 

35 G. In step 31-G, the file is deleted by issuing an appropriate instruction to server process 354 (Figure 3B). 
Processing transfers from step 31-G (Figure 3A) through next step 31-J to for each filename step 31-C. If all 
filenames in the list have been processed, processing transfers from for each filename step 31-C to terminal 
step 31-K in which process 352A terminates. As indicated by arrows 360 (Figure 3B), all interaction between 
process 352A and server process 354 transpired entirely within computer 30B without use of network 356. 

40 After successful completion of the program, processing transfers from step 33 to step 34 (Figure 3A) in 

which server process 354 (Figure 3B) reports to client process 352 that the program completed successfully 
as represented by arrow 362. Note that this remote programming procedure involves only two uses of network 
communications media: a first to send the program or list of instructions to server process 354 as represented 
by arrow 358 and a second to receive from server process 354 notification of successful completion of the 

45 program as represented by arrow 362. Note also that client process 352 was able to request of server process 
354 an operation not explicitly provided by, and perhaps not even anticipated by the developers of, server proc- 
ess 354. 

However, remote programming encounters the same inefficiencies of remote procedure calling when a 
computer process seeks to coordinate manipulation of data on two or more computer systems. For example, 
so a process on computer X may seek to delete all files on computer system Y or computer system Z which have 
the same name, date of last modification and size as any file on computer X. Since server process 354 de- 
scribed above with respect to Figures 3A and 3B is capable of directly manipulating resources on the computer 
system on which the server process is executing, i.e. computer system Y, the server process is unable to co- 
ordinate data management spanning more than one computer system without producing the inefficiencies dis- 
ss cussed above in conjunction with remote process calling. 

An improvement over remote programming is described by C. Daniel Wolfson, et al., "Intelligent Routers". 
9th International Conference on Distributed Computing Systems at pp. 371-375 (1989). Wolfson et al. disclosed 
a system wherein a process could move from one computer system to another within a network. The process 
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directed its own movement through the network by issuing an instruction whose execution caused the process 
to be moved. The instruction specified to which computer system the process was to be moved. 

However, the solution in the form disclosed in Wolfson et al. was of limited functionality. Processes were 
required to be configured to comport with the specific requirements of the computer system to which the re- 

5 spective processes moved. Processes were not able to communicate with one another; processes instead di- 
rectly stored or directly retrieved data from the mass memory of the computer system within which the respec- 
tive processes were executing. One process could only interact with another process only if both processes 
knew the precise location within mass memory where messages were to be stored and/or retrieved. 

The system disclosed by Wolfson et al. did not provide any security. Thus, to the extent that the Wolfson 

10 et al. system allowed one process to interact with another process, a malicious process could interfere with 
the execution of a second process. In addition, the set of instructions provided to processes of the system dis- 
closed by Wolfson et al. was very limited; only character string data and numerical data representing real num- 
bers were provided for. 

Another system similar to that disclosed by Wolfson et al. was that described by D. Tsichritzis et al.. "KNOs: 
15 KNowledge Acquisition, Dissemination, and Manipulation Objects", ACM Trans, on Office Information Sys- 
tems , vol. 5, no. 1. pp. 96-112 (1987). The system described by Tsichritzis et al. added to the system described 
by Wolfson et al. the generality of object-oriented programming. 

Object-oriented programming organizes data and instructions into "objects" in which data represent the 
"state" of an object and instructions are grouped into tasks or "operations" that the object can "perform". Object- 
20 oriented programming represents a very useful conceptual framework in which problems solved by a computer 
may be more easily reduced to a series of computer instructions. 

Objects created in an object-oriented environment are grouped into classes. Objects of a class have states 
of the same structure and perform the same operations. The system disclosed by Tsichritzis et al. did not pro- 
vide for the mobility of class definitions; therefore, objects of a given class created within the environment de- 
25 scribed by Tsichritzis et al. could only travel to those computer systems for which the given class was defined. 
Additionally, objects in the environment described by Tsichritzis et al. were represented in a form that required 
that the computer systems of the network, within which objects could travel, were homogeneous. 

The system taught by Tsichritzis et al. further described an instruction by which a first process, i.e.. a "head" 
process, could create copies of itself. The copies were called "limbs". Tsichritzis et al. taught that limbs could 
30 be sent to remote computer systems at the direction of the head process. However, the limbs were not active; 
the computer instructions of a limb were executed only at the direction of the head process. Directing the ac- 
tivity of a limb process positioned in a remote computer system required that the head process issue commands 
to the limbs across network communications media, involving considerable time and expense in large net- 
works. 

35 Further inefficiencies were found in the system taught by Tsichritzis et al. when a small computer, e.g., a 

personal computer, was connected to a large network through a large computer, e.g., a mainframe computer. 
For example, to send many limbs to various computers of the network, the small computer was required to 
send many identical limbs between the small computer and the large computer. As limbs, which are copies of 
the head process, could be quite large, inefficiencies in such a system could have been quite substantial. 

40 Tsichritzis et al. taught a system wherein a first process communicated with a second processes by giving 

to the second process a reference to the first process. A reference is data which identifies an object and which 
grants access to the object identified. As the second process contained a reference to the first process, the 
second process could request that the first process execute specific computer instructions which were con- 
tained within the first process. However, as the first process provided the second process with a reference to 

45 the first process without simultaneously obtaining a reference to the second process, the second process had 
access to the first process and the first process did not have reciprocal access to the second process. Such 
a system permitted a "malicious" process, i.e., a process designed by a malicious programmer or inadvertently 
designed to harm other processes, to gain access to a second process without granting reciprocal access. 
Thus, in spite of the achievements of Wolfson et al. and Tsichristzis et al., neither discloses a system in 

50 which new classes of objects and processes can be created and can be transported to and processed by com- 
puter systems within the network which do not contain class definitions for the new classes. Neither does either 
Wolfson et al. or Tsichristzis et al. disclose a mechanism for implementing a complex and hierarchical security 
scheme. Furthermore, neither Wolfson et al. nor Tsichristzis et al. disclose computer processes which can in- 
teract with one another but which cannot gain access to other processes without granting reciprocal access. 

55 Furthermore, neither Wolfson et al. nor Tsichristzis et al. disclose computer processes which can travel to 

several computer systems simultaneously by creating several autonomous clones of a process and transport- 
ing the clones to respective computer systems. The limbs taught by Tsichristzis et al. are not autonomous as 
the computer process controls the actions of limbs at remote computer systems. Furthermore, neither Wolfson 
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et al. nor Tsichristzis et al. disclose efficient transportation of the clones to the respective computer systems 
in which transportation of redundant information across network communication media is minimized. 

SUMMARY OF THE INVENTION 

5 

According to the principles of this invention, a set of interpreted, object-oriented computer instructions is 
used to create novel computer processes that are executed in a distributed computer system. A particular proc- 
ess that utilizes the set of computer instructions is activated by an engine that is executing within the distributed 
computer system. The engine interprets and effectuates the instructions of the particular process within the 

10 distributed computer system. 

Each engine in the distributed computer system interprets the instructions that define a process uniformly. 
In other words, the instructions which comprise a process and which are interpreted by a first engine do not 
depend on the particular configuration of the computer system within which the first engine is executing. The 
instructions, therefore, can be moved to and interpreted by a second engine, even if the first and second en- 

75 gines are executing within two separate computer systems whose operating systems and hardware are other- 
wise generally incompatible. The interpreted instructions are implemented by using interfaces to communica- 
tion, storage, computing and other subsystems of the computer system within which the. engine is executing. 
These interfaces, which collectively form part of one embodiment of the present invention, are described in 
Appendix C, which is a part of this disclosure and is incorporated in its entirety herein by reference. 

20 Two or more engines are interconnected to form a network. The network is a universe within which com- 

puter processes of this invention travel. In one embodiment, the network encompasses computer systems that 
would normally be considered clients of, and not part of, other networks. For example, one embodiment of the 
network of this invention encompasses the workstations which are connected by the network. The term "work- 
station" is used herein to describe a computer system which is used for purposes other than the transportation 

25 of information to other computer systems. The engines of this invention are interconnected so that engines 
are capable of moving computer processes among themselves. 

To transport a particular computer process, the computer process is suspended and the execution state 
of the computer process is preserved. The instructions of the computer process, the preserved execution state, 
and objects owned by the computer process are packaged, or "encoded", to generate a string of data that is 

30 configured so that the string of data can be transported by all standard means of communication used to form 
a network. In one embodiment, the string of data is transported between engines as specified by the protocol 
described in Appendix D, which is a part of this disclosure and is incorporated herein in its entirety by reference. 

Once transported to a destination computer system of the network, the string of data is decoded to gen- 
erate a computer process within the destination computer system. The decoded computer process includes 

35 those objects encoded as described above and has the preserved execution state. The destination computer 
system resumes execution of the computer process. The instructions of the computer process are executed 
by the destination computer system to perform complex operations, including defining, creating and manipu- 
lating data objects and interacting with other computer processes executed by the destination computer sys- 
tem. As computer processes are uniformly interpretted throughout the network and are encoded and decoded 

40 for transport between computer systems, the computer processes of this invention provide a new level of func- 
tionality and versatility in intercomputer communication. 

In one embodiment, two classes built into the set of computer instructions of this invention are an agent 
class and a place class. Instructions formed using the agent class are interpreted by an engine to form an "agent 
process", sometimes referred to herein simply as "an agent". An agent is an active object in that an engine 

45 initiates execution of an agent upon creation of the agent. The agent class provides instructions which enable 
an agent to (i) examine and modify itself, (ii) transport itself from a first place process, which is described more 
completely below, in the network to a second place process in the network, and (iii) interact with other agents 
found at the second place process. The first and second place processes can execute within two separate com- 
puter systems of the network. Thus, an agent can travel from a first computer system to a second computer 

50 system. 

An agent can contain information which is carried with the agent from the first place process to the second 
place process. Additionally, the extensibility, generality and functionality of the set of computer instructions 
discussed more completely below provide tremendous flexibility and control in determining, according to the 
instructions which comprise an agent, how and to what destination the agent, and the information contained 
55 therein, travels. 

The power of agents is counterbalanced by "permits". A permit limits the particular capabilities of a par- 
ticular agent on particular occasions. The permit of an agent specifies which of several of the operations de- 
fined for the agent class can or cannot be performed by the agent. The permit further limits the amount of 
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processing resources the agent can consume and the time at which the agent expires. Additionally, the permit 
specifies the priority of execution of the agent relative to other agents. 

Instructions formed using the place class are interpreted by an engine to form a "place process", some- 
times referred to herein simply as "a place". A place is also an active object, and the place class provides in- 
5 structions which enable a place to examine and modify itself and to serve as a venue for agents and a context 
in which agents can interact. Agents each occupy a respective single place. Additionally, each place can oc- 
cupy a single other place. 

Places provide a degree of privacy and security for agents. For example, an agent, which is configured to 
avoid contact with other agents, can occupy a place which is not generally known to other agents, or which 
w denies ingress to other agents. Conversely, an agent, which is configured to provide services publicly to a large 
number of agents, can occupy a place which is widely known to other agents and which grants ingress to other 
agents. 

Agents cannot interact at a distance; i.e.. no two agents can interact unless both occupy the same place. 
To interact with a second agent occupying a second place, a first agent, which occupies a first place, issues 
15 a command causing the first agent to be transported to the second place as discussed below with respect to 
the "go" operation. While both the first and second agents occupy the second place, the first agent can interact 
with the second agent. 

Thus, the processes of this invention are a novel implementation of "remote programming," and not the 
more familiar "remote procedure calling" paradigm. Remote programming improves upon remote procedure 
20 calling by (i) enabling processes to interact without communicating across network communications media and 
(ii) improving the performance of the interactions between processes by eliminating communication across 
network communications media which often has high-latency. 

The movement of an agent process, from a first place process in a first computer system to a second place 
process either in the first computer system or in a second computer system is called a trip. The agent initiates 
25 the trip by using a "go" operation, which is defined in the agent class. The agent controls the movement either 
through the network or within the computer system by creating and submitting, as an argument to the "go" 
operation, a ticket which defines the trip. In one embodiment, the ticket specifies the place to which the agent 
is to travel, the "way" by which the agent is to travel, the amount of time in which the trip must be completed, 
and an indication of the urgency of the trip, i.e., the priority of the trip relative to other trips by other agents 
30 that may be concurrently scheduled. 

The ticket can identify the destination place by specifying the address, name, class or any combination 
of the address, name and class of a place to which the agent is to travel. The destination of the trip is any 
place of the specified address, name and/or class which grants the agent ingress within the time permitted 
by the ticket. 

35 In the "go" operation, the agent is moved from a first place to a second place as follows: (i) the agent is 

suspended and the execution state of the first agent is preserved; (ii) the agent is represented in a standardized 
form, i.e., an octet string, which includes representation of the agent's preserved execution state; (iii) the stan- 
dardized form is transported from the first place to the second place, potentially involving the transfer of the 
standard form from a first computer to a second computer; (iv) the agent at the second place is formed from 

40 the standardized form, including the execution state represented in the standardized form; and (v) interpretation 
of the agent is resumed, the agent initially having the execution state represented in the standardized form. 

As mentioned above, the set of computer instructions of the present invention is object-oriented. Therefore, 
all objects formed according to the present invention are organized into classes. All classes in the present in- 
vention are represented by data objects which can be moved along with an agent. Thus, classes, which are 

45 not defined within a place, can nevertheless be used by an agent travelling to the place simply by the agent 
defining the classes and transporting the corresponding class objects to the place. 

Every object in one embodiment of the present invention is owned by a process, i.e., either an agent or a 
place. When an agent travels from a first place to a second place, all objects owned by the agent are effectively 
moved to the second place along with the agent. However, as discussed below, objects which are equivalent 

50 to objects already occupying the second place are not transported in one embodiment of the present invention. 
In addition to the objects owned by the agent, all class objects defining classes of which those objects are 
members are moved along with the agent to the second place. A class object is an object constructed in ac- 
cordance with the set of computer instructions described below and in Appendix A which represents a class 
of objects. 

55 Thus, if an object owned by an agent travelling to a second place is a member of a class not defined in 

the second place, the object can still travel with the agent as the agent also carries to the second place class 
objects defining the classes of which the object is a member. In the prior art, a process which travelled from 
a first computer to a second computer could only process data objects which belonged to classes defined on 
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the second computer. Class definitions were not typically transported with migrating processes in the prior art. 
As new classes can be formed within a first place and members of those new classes are free to travel to other 
places for which those new classes are not defined, the present invention provides agents a level of extensi- 
bility, mobility and generality not found in the prior art. 

5 In the present invention, many classes of objects are defined at multiple places and therefore do not need 

to be moved to such places. Class objects and any other objects, which are likely to be found at many places 
are made interchangeable in one embodiment of the present invention. 

Interchangeable objects each have a digest. An interchangeable object, which is owned by an agent that 
is travelling from a first place to a second place, does not travel with the agent. Rather, the digest of the in- 
fo terchangeable object is moved with the agent to the second place. When the agent arrives at the second place, 
interchangeable objects in the computer system which contains the second place are examined to determine 
whether any of the interchangeable objects has a digest equal to the digest transported with the agent. If such 
an interchangeable object is found in the computer system which contains the second place, the interchange- 
able object is substituted for the interchangeable object, which was left behind at the first place. 

15 If, however, no such interchangeable object is found at the second place, the interchangeable object left 

behind at the first place is moved to the second place. In this way, the movement of objects across network 
communications media is avoided when equivalent objects are present at the destination place. In particular, 
as class objects are interchangeable, an agent travelling to a second place causes the movement to the second 
place of only those class objects defining classes which are not defined within the second place. Avoiding un- 

20 necessary movement of class objects through the network makes practical the movement of objects owned 
by an agent to places which contain no definition of one or more classes to which those objects belong. 

In one embodiment of the present invention, classes are identified by citations. In a computer network 
having many computer systems supplied by different vendors, various versions of the disclosed instruction 
set can be implemented on various computer systems to which and from which agent processes can travel. A 

25 citation is an object which is used to identify classes or objects which are forward-or backward-compatible 
with one another. Therefore, an instruction requiring use of an object of a first class, or the first class itself, 
can use an object of a second class, or the second class itself, depending on the particular requirements of 
the instruction, if the second class is backward-compatible with the first class. 

An agent, occupying a first place, is also capable of creating one or more clones of the agent and moving 

30 each clone to a respective place. A clone is an agent process which is the result of duplicating an existing agent 
process. An agent initiates and controls the creation of one or more clones, and the movement of each clone 
to a respective place process by performance of operation "send." The agent specifies the number of clones 
to be created and defines the corresponding trips by creating one or more tickets which are supplied as argu- 
ments to operation "send". Each ticket defines a trip to be taken by a respective clone of the agent. The number 

35 of tickets supplied by the agent defines the number of clones created. 

Once a clone of the agent is moved to a second place, the clone initially has the execution state of the 
agent at the time the clone was created. Thus, when the clone arrives at a second place, the clone continues 
to execute so as to simulate the movement of the agent to the second place as described above with respect 
to operation "go." 

^0 in the prior art, a first process, i.e., a head process, created limb processes which had the same interface, 

i.e., could generally perform the same operations, as the head process. Limb processes did not act except as 
directed by the head process and could move to remote computer systems only at the direction of the head 
process. 

In the present invention, however, a clone is autonomous and is not controlled by the agent which created 
45 the clone. For example, the clone can be configured to ignore all attempts by the agent to arrange a meeting, 
which is discussed below, whereby the agent and the clone can interact. The agent must attempt to interact 
with a clone of the agent in the same way the agent attempts to interact with any other agent, as discussed 
below. As the clone is autonomous, the clone occupying the second place can travel to a third place by per- 
formance of operation "go" without being so instructed by the agent and even without the consent of the agent. 
50 As limb processes of the prior art were not active and acted only at the direction of a head process, the 

head process and a remote limb process necessarily interacted across network communications media. The 
paradigm of this prior art system is therefore more closely related to remote procedure calling. In contrast, 
clones of agents formed in accordance with the present invention are active and autonomous and embody all 
of the instructions which form the agent. Therefore, no interaction is required (in fact, no interaction is allowed) 
55 across network communications media. Therefore, the paradigm of the present invention is more closely re- 
lated to remote programming. The present invention therefore represents a significant increase in generality 
over the prior art. 

Increases in efficiency in one embodiment of the present invention are realized in performance of operation 
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"send" by deferring cloning of an agent as long as possible. For example, a first clone and a second clone are 
to be sent to a first place and a second place, respectively. Suppose that the agent is executing within a first 
computer system, that the first place is executing within a second computer system, and that the second place 
is executing within a third computer system. Suppose further that in travelling to the first and second places, 

5 the first and second clones must travel through an engine executing on a fourth computer system. In such a 
case, a single clone is formed and transported to the engine executing within the fourth computer system. Thus, 
only a single clone is created within the engine interpreting the original agent thereby saving space within that 
engine and only a single clone is transported across network communications media to the fourth computer 
system thereby saving time in transporting clones to the fourth computer system. The engine executing within 

w the fourth computer system forms from the single clone the first and second clones and transports the first 
and second clones to the first and second places, respectively. 

As an agent can own objects which account for a substantial majority of the size of the agent, e.g., a ras- 
terized graphical image such as a facsimile transmission or digitized sound, avoiding sending several copies 
of such large objects, each copy owned by a respective clone, to a single engine saves substantial time and 

15 expense. 

A first agent, occupying a place, can initiate a meeting between the first agent and a second agent occu- 
pying the place. During such a meeting, the first agent can transfer to and receive from the second agent data 
in the form of objects, and the second agent process can transfer to and receive from the first agent data in 
the form of objects. 

20 The present invent;. = represents a significant improvement over a prior art system which teaches the post- 

ing of messages on a virtual bulletin board by a first process. The messages are then "read" by the intended 
recipient process. In the prior art system, a first process gives to a second process a reference to the first proc- 
ess by posting the reference on the virtual bulletin board. However, since there is no mechanism for simulta- 
neous exchange of references, the second process has access to the first process before giving to the first 

25 process a reference to the second process. Thus, there is no mechanism to prevent "malicious" processes from 
gaining access to other processes without granting to the other processes access to themselves. 

The present invention represents an improved method of establishing contact between two processes 
such that a first process cannot obtain access to a second process without simultaneously granting to the sec- 
ond process access to the first process. 

30 In one embodiment of the present invention, two agents can interact only if both agents occupy the same 

place and the place is a meeting place. Ameeting place is a place that is a member of a class of meeting places, 
which is a subclass of the class of places. A first agent directs that a meeting be arranged between the first 
agent and a second agent by issuing an instruction directing the meeting place to arrange the meeting. The 
issued instruction is called operation "meet", and the first agent's issuance of the instruction is called "request- 

35 ing a meeting". 

The first agent supplies, as an argument to the instruction, a petition defining the meeting. The petition 
defines the meeting by specifying the second agent as the petitioned agent. The second agent is specified 
by specifying the name and/or the class of the second agent. The petition further defines the meeting by spec- 
ifying the amount of time in which the meeting must be arranged or abandoned. 

40 In arranging the meeting, the meeting place supplies to the second agent the name and class of the first 

agent and indicates that the first agent has issued an instruction requesting a meeting with the second agent. 
The second agent examines the name and class of the first agent and responds to the meeting place either 
accepting or rejecting the meeting with the first agent. 

If the meeting is rejected, the first agent is informed that the second agent is not available. If the meeting 

45 is accepted, the meeting place gives to the second agent a reference to the first agent and gives to the first 
agent a reference to the second agent. With a reference to the second agent, the first agent (i) can direct the 
second agent to perform operations; (ii) can supply to the second agent objects as arguments; and (iii) can 
receive from the second agent objects as results. As the second agent has a reference to the first agent, the 
second agent has similar capabilities with respect to the first agent. 

50 Either the first or the second agent can terminate the meeting between the two by issuing an appropriate 

command. The meeting place, in performing an operation "part" in response to the issued command, voids 
any references to the second agent contained within the first agent and voids any references to the first agent 
contained within the second agent, thereby terminating interaction between the two agents. 

The present invention represents a significant improvement over the prior art as a first agent cannot gain 

55 access to a second agent unless the second agent agrees or without granting to the second agent access to 
the first agent. Additionally, since two agents cannot interact unless both occupy the same meeting place, in- 
termediate levels of security are available to agents. For example, an agent can protect itself from other agents 
by occupying a meeting place whose location is not widely known by other agents. Inversely, an agent, which 
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is designed to be highly visible, may occupy a well-known meeting place. No such mechanism is available in 
the prior art. 

BRIEF DESCRIPTION OF THE DRAWINGS 

5 

Figure 1 shows the structure of computer systems of the prior art. 

Figure 2A is a logic flow diagram of a prior art method using remote procedure calling. 

Figure 2B shows a prior art network implementing remote procedure calling. 

Figure 3A is a logic flow diagram of a prior art method using remote programming. 
w Figure 3B shows a prior art network implementing remote programming. 

Figures 4A and 4B show the movement of an agent process through a network constructed in accordance 
with the present invention. 

Figures 5A and 5B show processes, formed in accordance with the principles of the present invention, exe- 
cuting within a computer system. 
15 Figure 5C shows a portion of a class hierarchy graph in accordance with one embodiment of the present 

invention. 

Figures 6A-6C show the movement of an agent process through a network formed in accordance with the 
present invention. 

Figures 7A-7E show the movement of clones of an agent process through a network formed in accordance 
20 with an aspect of the present invention. 

Figures 8A-8F illustrate interaction between two agent processes by using operation "meet". 
Figures 9A-9E illustrate the interrelations of place processes formed in accordance with one aspect of the 
present invention. 

Figure 1 0 shows the structure of a computer network formed in accordance with the principles of the pres- 
25 ent invention. 

Figures 11 A and 11B show alternative representations of the network shown in Figure 10. 
Figure 12 is a diagram illustrating the class relationships of an agent process in one embodiment of the 
present invention. 

Figures 1 3A and 1 3B illustrate the state of an agent process formed in accordance with the present inven- 
30 tion immediately before and after, respectively, movement of the agent process within a computer network of 
the present invention by performance of operation "go". 

Figures 14A-14G are logic flow diagrams which illustrate the steps taken to move an agent process through 
a network in accordance with the present invention by performance of operation "go". 

Figures 15A-15E show the structure of a network formed in accordance with the present invention and 
35 illustrate the movement of an agent process through the network. 

Figure 16 shows the structure of an agent process including a permit. 
Figure 17 shows the structure of the permit of Figure 16. 

Figure 1 8A shows the structure of the ticket of Figure 1 3A including a teleaddress. a citation, a telename, 
and a way. 

40 Figure 1 8B shows the structure of the way of Figure 18A. 

Figure 19 shows the structure of the telename of Figure 18A. 

Figure 20A shows a dictionary formed according to one embodiment of the present invention. 
Figure 20B shows the structure of a finder constructed according to one embodiment of the present in- 
vention. 

45 Figure 21 shows the structure of an encoded agent in accordance with one embodiment of the present 

invention. 

Figures 22A and 22B show the state of an agent process immediately prior to and following, respectively, 
performance of operation "entering". 

Figure 22C is a logic flow diagram illustrating the steps taken in performance of operation "entering" in 
50 accordance with one embodiment of the present invention. 

Figures 23A and 23B show a portion of the state of a process immediately preceding and following, re- 
spectively, performance of operation "exiting". 

Figures 24A-24C are logic flow diagrams illustrating the steps taken in transporting an agent process 
through a network in accordance with an aspect of the present invention. 
55 Figure 24D shows the structure of a repository of interchanged objects which is used in the steps shown 

in Figures 24A-24C. 

Figure 25 shows a computer network formed in accordance with the principles of the present invention. 
Figures 26A and 26B show a portion of the state of an agent process immediately prior to and following, 
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respectively, performance of operation "send". 

Figure 26C shows the state of a clone of the agent process immediately following performance of operation 
"send". 

Figures 27A and 27B show the state of a engine process before and after, respectively, formation of clones 
5 of an agent process in performance of operation "send". 

Figure 28 shows the computer network of Figure 25 in which clones of the agent process have travelled 
to respective computer systems of the computer network in performance of operation "send". 

Figures 29A-29E show a computer network through which clones of an agent process travel according to 
another aspect of the present invention referred to as "deferred "cloning". 
10 Figure 30A shows the structure of a send frame including a nil and a list of tickets. 

Figure 30B shows the structure of an encoded clone of an agent process formed in accordance with an 
aspect of the present invention. 

Figures 31 A and 31 B show the state of a process immediately preceding and following, respectively, per- 
formance of operation "meet". 
15 Figure 32 is a logic flow diagram of the steps taken in performance of operation "meet". 

Figure 33 shows a portion of the state of an agent process including a set of contacts. 
Figures 34A and 34B show the state of a process immediately preceding and following, respectively, per-_ 
formance of operation "meeting". 

Figure 35 is a logic flow diagram illustrating the steps taken in performance of operation "meeting" in ac- 
20 cordance with one embodiment of the present invention. 

Figure 36 shows the state of two agent processes which are interacting in accordance with an aspect of 
the present invention. 

Figures 37Aand 37B show a portion of the state of an agent process immediately preceding and following, 
respectively, performance of operation "part". 
25 Figure 38 shows the state of the agent processes shown in Figure 36 immediately following performance 

of operation "part". 

Figures 39A-39F show a portion of the state of a first agent process during interaction with a second agent 
process in accordance with the present invention. 

Figure 40 is a logic flow diagram illustrating steps taken by the second agent process during the interaction 
30 shown in Figures 39A-39F according to one embodiment of the present invention. 

Figure 41 Ashows the structure of a class definition in accordance with one aspect of the present invention. 

Figure 41 B shows the structure of a class object formed in accordance with one embodiment of the present 
invention. 

Figure 41 C shows the structure of a class object formed in accordance with a second embodiment of the 
35 present invention. 

Figure 42 shows the structure of an interface object formed in accordance with the present invention. 
Figure 43 shows the structure of a feature definition including a set, an identifier, and a boolean. 
Figure 44 shows the structure of an attribute definition including a constraint and a boolean. 
Figure 45 shows the structure of an operation definition including a constraint and a list, which in turn in- 
40 eludes a constraint. 

Figure 46 shows the structure of a constraint. 

Figure 47 shows the structure of an implementation object which includes two lists and six lexicons. 
Figure 48 shows the structure of a method which includes a procedure and a list, which in turn includes 
an identifier. 

45 Figure 49 shows the structure of the procedure of Figure 48. 

Figure 50 shows the structure of a citation which includes a telename, two integers, and an identifier. 

Figure 51 shows the structures of two cited objects, each of which includes a respective citation. 

Figure 52A is a logic flow diagram illustrating the steps taken in performance of operation "do". 

Figure 52B shows the structure of a predefined frame which includes an integer and a procedure. 
so Figure 53 shows the execution state of a process which includes a stack, which in turn includes a user 

frame. 

Figure 54 shows the state of the user frame of Figure 53. 

Figures 55A and 55B combine as shown in Figure 55C to form a single logic flow diagram illustrating the 
steps taken in performance of a user-defined operation. 
55 Figure 56A shows the execution state of a process which includes a stack, which in turn includes a frame. 

Figure 56B shows the execution state of the process of Figure 56A and a second frame. 

Figure 56C shows the execution state of the process of Figures 56A and 56B. including the stack, which 
in turn includes the first-mentioned frame and the second frame. 
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Figure 57 is a logic flow diagram illustrating the steps taken in selecting a feature definition and a method 
from the class hierarchy in accordance with the present invention. 

Figure 58A is a diagram showing the hierarchy of the classes of which a list is a member. 

Figure 58B is a diagram showing the hierarchy of the classes of which class "List" is a member. 
5 Figure 59 is a logic flow diagram illustrating the steps taken in the initialization of an object. 

Figure 60 is a logic flow diagram illustrating the steps taken in performance of operation "if*. 

Figure 61 is a logic flow diagram illustrating the steps taken in performance of operation "either". 

Figures 62A and 62B show a portion of the execution state of a process immediately preceding and fol- 
lowing, respectively, performance of operation "select". 
w Figure 63 is a logic flow diagram illustrating the steps taken in performance of operation "select". 

Figure 64 shows the state of a predefined frame which represents the dynamic state of a performance of 
operation "select". 

Figure 65 is a logic flow diagram illustrating the steps taken in performance of operation "while". 

Figures 66A and 66B show a portion of the execution state of a process immediately prior to and imme- 
15 diately following, respectively, performance of operation "catch". 

Figure 67 is a logic flow diagram illustrating the steps taken in performance of operation "catch". 

Figure 68 is a logic flow diagram illustrating the steps taken in performance of operation "loop". 

Figure 69 shows the structure of a repeat frame which includes an executed object and two integers. 

Figure 70 is a logic flow diagram illustrating the steps taken in performance of operation "repeat", 
20 Figure 71 shows the execution state of a process which includes a stack which in turn contains, from top 

to bottom, a user-defined frame, ■< predefined frame, a repeat frame, and a second user-defined frame. 

GLOSSARY OF TERMS 

25 "Abstract Class": A class which is abstract has no instances. An abstract class can have subclasses, and an i 
abstract class can define features, methods, and properties which are inherited by the subclasses of the ab- 
stract class. 

"Agent": An agent is a process which occupies a place and which is mobile, i.e. can move from a first place to 
a second place. 

30 "Arguments": An argument is an object "consumed" by performance of an operation as input data. In other 
words, an argument is an object transferred from the requester to the responder immediately prior to perfor- 
mance of the operation by the responder at the request of the requester. 

"Attribute": An attribute is a feature which either retrieves or sets information regarding the internal state of 

an object. Usually the information pertains to the object itself, but sometimes the information pertains to the 
35 reference by which the object is identified in invoking the attribute. An attribute is a pair of operations in which 

one sets, and the other retrieves, information regarding the internal state of the responder. 

"Authority": An authority is an entity which owns and controls various resources in the network. An example 

of an authority is a user of the network. Authorities are created administratively and cannot be created pro- 

grammatically, i.e., cannot be created at the request of a process. 
40 "Class": A class defines (i) zero or more properties, which define the internal states of the members of the class, 

(ii) zero or more methods, which define the internal behavior of the members of the class, and (iii) zero or more 

features, which define the external behavior of the members of the class. 

"Concrete Class": A class which is concrete can have instances. 

"Engine Place": Every engine contains exactly one engine place which represents the engine itself. 
45 "Engine": An engine is a machine in a computer system which manages objects, primarily processes, and exe- 
cutes instructions. An engine is typically a computer process executing within a computer system in addition 
to an operating system and various user applications. One or more engines can be executing within each com- 
puter system of a network. Each engine processes at least one place. 

"Exception": An exception is an object "thrown" by performance of a feature if the feature fails to be performed 
50 completely and successfully. An exception, as the term is used herein, is alternatively a condition which causes 
such an object to be thrown. The responder is said to "throw" an exception, rather than "produce" an exception, 
because an exception arises from the failure of an operation and is therefore distinct from a result which is 
produced by a successful operation. The distinction between producing a result and throwing an exception is 
described in more detail below and in Appendix A which is hereby incorporated herein in its entirety by refer- 
55 ence. 

"Feature": A feature is a task that an object can be directed to perform. The task is carried out by a method, 
which includes a set of computer instructions. Performance of a feature is accomplished by execution of the 
computer instructions of the feature's method. A feature is associated with a specific class of objects, and per- 
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formance of a feature can vary with the specific internal state of the object performing the feature. Features 
are conceptually divided into the two categories: (i) attributes and (ii) operations. 

"Frame": A frame is an object which records the dynamic state of a method implementing a feature during per- 
formance of the feature. A frame is used by an engine to maintain information regarding a method which the 
5 engine is executing, including information identifying the object performing the feature implemented by the 
method and the particular instruction that is currently executing. 

"Identifier": An identifier is an object which can reference a second object. The "text" of an identifier is a string 
which distinguishes the identifier from other identifiers within a particular scope. The various scopes of iden- 
tifiers are discussed in greater detail in Appendix A. 
w "Implementation": An implementation is a set of computer steps performed in performance of a particular fea- 
ture. An "implementation object" is an object defining the various implementations of the various features of 
a class. 

"Instance": An object is an instance of a class if the object is a member of that class and is not a member of 
any subclass of that class. 

15 "Interface": An interface defines a particular attribute or the particular arguments consumed and the result pro- 
duced by performance of a particular operation. An "interface object" is an object defining the various interfaces 
of the various features of a class. 

"Member": An object is a member of the class of which the object is an instance and any superclasses of that 
class. 

20 "Method": A method is a set of computer instructions whose execution constitutes performance of a particular 
feature. A "method object" is an object defining a method. A method has a dynamic state during performance 
of the method, i.e., execution of the instructions of the method. The dynamic state of a method is represented 
by a frame. 

"Network": All engine places, the computer systems in which the engine places execute and communications 
25 apparatus connecting those computer systems collectively form a network. 

"Object": An object is an element in a computing environment within a computer system. An object has an in- 
ternal state defined by zero or more properties, an internal behavior defined by zero or more methods, and 
an external behavior defined by zero or more features. 

"Operation": An operation is a feature for which an interface and implementation is defined. 
30 "Place": A place is a process which is a locale for zero or more processes. A place can occupy a second place. 
The first-mentioned place is a subplace of the second place, and the second place is a superplace of the first 
place. 

"Primitive": A primitive is an object that can be used in the formation of a procedure or a method, and that there- 
fore can serve as an instruction. 

35 "Process": A process is an object which constitutes an autonomous computation. A process is autonomous be- 
cause a process performs a method without being requested to do so by another object. A process commences 
performance of a central method upon creation of the process, and the process is destroyed upon completion 
of the central method. Every object is owned by exactly one process. Every process is owned by itself. As 
used herein, the term "computer process" refers to a series of instructions carried out by a computer system, 

40 which is a more general and well-known definition. 

"Property": A property is an object which represents a part of the internal state of a second object. 
"Reference": A reference is a data structure which identifies a particular object. An object, in being directed 
to perform a feature, is identified by a reference to the object supplied by the requester of the feature. Refer- 
ences are either protected or unprotected. An object cannot be altered or modified using a protected reference 

45 to identify the object. 

"Region": A region is one or more engine places within a network which are controlled by a single authority. A 
region is generally distinguished by the close coordination and management of computer systems which sup- 
port the engine places of the region. The transportation of agents within a region is therefore generally quicker 
and less expensive than transportation of agents between regions. A region can be, for example, a local area 

so network which is connected to a wide area network. 

"Requester": A requester is an object which directs another object, i.e. the responder, to perform a feature. 
The requester supplies zero or more objects as input data to the responder of the feature requested and re- 
ceives zero or one object as output data from the responder of the feature. Directing an object to perform a 
feature is alternatively called "requesting" the object to perform the feature. 

55 "Responder": A responder is an object performing a feature at the direction of another object, i.e. the requester. 
The responder receives zero or more objects as input data and supplies zero or one object as output data in 
performing the feature. A responder is alternatively called a "responding" object. 

"Result": A result is an object "produced" by performance of an operation as output data. In other words, a result 
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is an object transferred from the responder to the requester immediately following performance of an operation 
by the responder at the request of the requester. 

"Subclass": A subclass inherits methods, properties, and/or feature definitions from one or more classes. A 
subclass can define one or more properties, methods, and/or features which are not inherited from any other 
5 class and can reimplement a feature which is inherited from another class by defining a new implementation 
of the feature. 

"Superclass": The classes from which a subclass inherits properties, methods, and/or features are superclass- 
es of the subclass. 

"Virtual Place": Every place which is not an engine place is a virtual place. 

10 

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT 

According to the principles of this invention, a novel set of computer processes are used to route a particular 
computer process to a selected computer system contained in a plurality of interconnected computer systems 

15 and to execute the particular computer process on the selected computer system. The computer processes of 
this invention are defined, in one embodiment, in terms of object-oriented computer processes. The computer 
processes of this invention include (i) an instruction set that defines the various operations in the process and 
(ii) an engine that interprets the instruction set and controls operation of a central processing unit (CPU) in 
performance of the computer processes. 

20 As explained more completely below, the particular computer process directs its own movement, i.e., 

transportation, through the computer network by executing an instruction which identifies a destination com- 
puter system within the network and directs that the particular computer process be transported there. While 
executing within the destination computer system, the particular computer process may have access to infor- 
mation which is not available elsewhere in the network. The particular computer process can access that in- 

25 formation and use that information to determine to which other compute; systems to travel. As explained more 
completely below, the present invention provides computer processes v.v.h a level of mobility, extensibility and 
generality not found in the prior art. 

In remote programming paradigms typically found in the prior art. a computer process does not direct its 
own movement, but is sent from a source computer system to execute within a destination computer system. 

30 If the computer process cannot direct its own movement throughout the network, the computer process cannot 
select further destination computer systems to which to travel on the basis of information obtained by the com- 
puter process at the destination computer system. Thus, such a computer process must return to the source 
computer system with the information obtained before being sent to a second destination computer system. 
As computer processes of the present invention can direct their own movement through the network, computer 

35 processes of the present invention represent a substantial extension of the traditional remote programming 
paradigm. 

Existing remote programming systems, which provide processes which direct their own movement through 
a computer network, lack generality and extensibility. Such systems lack generality in that such systems (i) 
are limited to homogeneous computer networks or (ii) require that a travelling process in a heterogeneous net- 
40 work contain instructions which conform specifically to whichever computer system is executing the process, 
i.e. computer systems to which the travelling process travels. In the present invention, a process travels within 
a heterogeneous computer network and the execution of the instructions of the process is independentof which 
particular computer system within which the process executes, i.e.. to which the process travels. As discussed 
below in greater detail, the computer instructions disclosed below are implemented uniformly by each of the 
45 computer systems of a heterogeneous network. Thus, a process formed in accordance with the present inven- 
tion can travel to any computer system within a heterogeneous computer network and execute there without 
any specific information regarding the nature of the computer system. 

Remote programming systems of the prior art typically lack extensibility in that a process cannot create a 
class of data objects and utilize data objects of that class within computer systems to which the process sub- 
so sequently travels. Many computer processes formed today are "object-oriented". As defined above in the Glos- 
sary of Terms, an object has (i) an internal state defined by a number of properties, (ii) an internal behavior 
defined by a number of methods, and (iii) an external behavior defined by a number of features. The properties, 
methods, and features of a group of objects with like properties, methods, and features are defined by a class. 
In prior art systems, a process which defines a class cannot use objects of the class while executing in com- 
55 puter systems to which the process subsequently travels. Transportation of class definitions with travelling 
processes is not feasible or practical in prior art systems because class definitions are not standardized; class 
definitions are generally very large and complex; and a single process generally uses objects of many classes. 

Class definitions are not "standardized" in that prior art systems are typically based on existing program- 
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ming languages which are not designed with mobile processes in mind. Therefore, class definitions in a process 
formed using one of these existing programming languages typically rely on information specific to the com- 
puter system within which the process is created, such as the specific memory addresses of portions of the 
class definitions. Reliance on such information, which is specific to a particular computer system, makes class 

5 definitions of prior art systems very difficult to transport to remote computer systems. 

In the present invention, classes are represented by class objects which are part of the disclosed computer 
instruction set. A process formed in accordance with the present invention includes class objects when trav- 
elling from one computer system to another. Thus, a process can define a class of object in a first computer 
system, travel to a second computer system, and utilize objects of the class within the second computer sys- 

w tern. Unnecessary delay and expense in transporting all classes utilized by a travelling process are eliminated 
by transporting only those classes which are not defined within the computer system to which the process trav- 
els. 

Additionally, the present invention provides efficiencies not found in the prior art in transporting several 
clones of a process to several destination computer systems simultaneously. As discussed more completely 

15 below, substantial efficiencies are realized by deferring creation of one or more clones of the process so long 
as the travel path of one clone coincides with the travel path of another clone. Clones, and this aspect of the 
present invention, are discussed further below. 

In remote programming systems, two processes share information by a first process giving a second proc- 
ess access to the first process. The first process gives the second process access to the first process without 

20 simultaneously obtaining access to the second process. In such a situation, the second process is free to in- 
terfere with the execution of the first process without compromising the security of the second process. In the 
present invention, a first process obtains access to a second process and simultaneously gives to the second 
process access to the first process through the cooperation and coordination of a third process. Further se- 
curity is provided as the second process either accepts or rejects such an exchange with the first process ac- 

25 cording to the configuration of the second process. The third process ensures that (i) the second process 
agrees to such an exchange and that (ii) each process gains access to the other process simultaneously such 
that neither process can interfere with the execution of the other process without affording a similar opportunity 
to the other process. 

A novel computer process of this invention is an agent process. An agent process is a computer process 

30 formed of the computer instructions disclosed below in Appendix A, which is a part of this disclosure and which 
is incorporated herein by reference in its entirety. Agent processes are each interpreted by another novel com- 
puter process of this invention, i.e.. an engine, and thereby effectuates the computer instructions disclosed 
below and in Appendix A. The term "interpreted" is used herein as it is understood in the art; a computer in- 
struction in a series of computer instructions is read and executed by an engine before the next computer in- 

35 struction in the series is read. 

Interpreting, rather than compiling, instructions of the disclosed instruction set provides greater generality. 
A first agent can travel from a first computer system to a second computer system and meet with a second 
agent there which gives to the first agent a procedure. The first agent can then perform the procedure which 
the first agent was not originally designed to perform. 

40 Yet another novel computer process of this invention is a place process. Place processes are dispersed 

throughout a computer network. Each agent process "occupies" a respective place process; i.e., a place proc- 
ess is part of the internal state of an agent process and therefore provides a context within which the agent 
process executes. Each agent process can initiate and control the agent process's transportation from a first 
place process to a second place process. "Agent" and "place" as used herein are shorthand terms for "agent 

45 process" and "place process", respectively. 

Figure 4A shows computer network 1 00 which includes computer systems 1 20A and 1 20B which are con- 
nected by communications link 102AB. Computer system 120A is executing place 220A and agent 150A. Agent 
1 50A occupies place 220Aas shown in Figure 4A. Computer system 120B is executing place 220B. Hereinafter, 
the statement that an agent or place occupies a particular place should be interpreted as including a statement 

50 that the agent or place is executing within the computer system which contains the particular place. 

Agent 150A issues an instruction to computer system 120A. In response to the instruction, agent 150Ais 
transported to a place, e.g. place 220B, specified in the instruction. The instruction is called operation "go", 
and the issuance of the instruction by agent 1 50A is called herein performance of operation "go" by agent 1 50A. 
Upon performance of operation "go" by agent 150A, (i) execution of agent 150A is suspended; (ii) agent 

55 150A is encoded into a standardized form which preserves the execution state of agent 150A; (iii) the stan- 
dardized form of agent 1 50A is transported to computer system 1 20B; (iv) agent 1 50A, including the preserved 
execution state, is decoded from the standardized form; and (v) execution of agent 150A is resumed within 
computer system 120B. After performance of operation "go" by agent 150A, agent 150A no longer occupies 
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place 220A and is no longer executing within computer system 1 20A; instead, agent 1 50A occupies place 220B 
and is executing within computer system 1 20B (Figure 4B). By enabling an agent to travel to a remote computer 
system in the midst of the agent's execution, the agent is free to travel to data which the agent is configured 
to access. 

5 A standardized form is a form to which agents are encoded for the transportation of the agent from one 

computer system to another. The standardized form preserves the execution state of the encoded agent such 
that the agent can be decoded at the destination computer system and execution of the agent can resume by 
executing the instruction of the agent which sequentially follows operation "go". Each computer system of the 
network of the present invention can maintain an agent in whatever form is convenient for carrying out the com- 

10 puter instructions included in the agent. However, in transporting an agent from one computer system to an- 
other, each computer system of the network must use the standardized form of an agent during transportation 
much the same way that two people must agree to the vocabulary and syntax of a single language to commu- 
nicate. The nature of the standardized form is discussed in greater detail in Appendices B, C and D, which are 
part of this disclosure, and in Appendices E and F which are incorporated in their entirety herein by reference. 

15 As an agent can direct its own movement, i.e., transportation, through the network, means must be pro- 

vided for specifying a number of parameters of a trip from a first computer system to a second computer sys- 
tem. A first parameter of a trip is the place to which the agent is transported, i.e., the destination of the trip. In 
one embodiment, a trip destination can be specified by name, by class, or by address. An address can be, for 
example, a location within a local area network. 

20 Frequently, two or more pathways exist between a first computer system and a second computer system. 

One pathway may be quick but expensive and another may be time consuming but inexpensive. In such a case, 
no single pathway is always preferred in the transportation of an agent. Therefore, a second parameter of a 
trip is the "way" and the "means" for travel of an agent. 

In addition, errors in configuring an agent for a trip to a nearby computer system can cause the agent to 

25 be inadvertently transported to distant computer systems at considerable expense to the creator of the agent. 
Therefore, an important parameter of a trip is the amount of time or resources that can be expended in trans- 
porting the agent before the trip is aborted. 

Yet another important consideration in controlling the transportation of agents throughout a network is se- 
curity. For example, if all agents travelling to a particular computer system are granted ingress, the particular 

30 computer system may become overburdened with many processes requiring substantial processing, and 
throughput of the particular computer system can suffer. Therefore, another parameter of a trip is the amount 
of resources the agent requires at the destination place. Thus, the agent can be denied ingress to the place if 
the resources required by the agent are more than the place is able or willing to provide. 

In one embodiment, a ticket 1306 (Figure 4A) controls the transportation of agent 150Aand specifies place 

35 220B as the destination place. As shown in Figure 4A, agent 150A contains ticket 1306. Ticket 1306 defines 
the trip taken by agent 1 50A from place 220A to place 220B. In one embodiment, ticket 1 306 specifies (i) the 
destination place of the trip, (ii) the "way" or pathway and "means" agent 150A is to take to the destination 
place, (iii) the maximum amount of time within which the trip must be completed before the trip is aborted and 
(iv) the amount of resources agent 1 50A asks to use at the destination place. By specifying the amount of re- 

40 sources agent 150Ais permitted to use at place 220B, place 220B can determine whether agent 150A requires 
more resources than place 220B is configured to provide. In such a situation, place 220B can deny ingress to 
agent 150A. Thus, using a ticket as described more completely below, an agent can completely define a pend- 
ing trip between a first place and a second place. 

As discussed above, the prior art process known to the inventors cannot manipulate objects of a class de- 

45 fined only in a previously occupied computer system. In other words, if a prior art process defines a class of 
objects and thereafter travels to a destination computer system, the process cannot manipulate objects of the 
class unless the destination computer system contains a definition of the identical class or the process defines 
the same class again within the destination computer system. As described in greater detail below, agents of 
the present invention, which travel from one place to another, transport definitions of classes which are not 

50 defined within the destination place. Thus, agents of the present invention can define a class within a first com- 
puter system, travel to a second computer system and manipulate objects of the class while executing within 
the second computer system. Agents of the present invention therefore represent a significant improvement 
over the known prior art processes. 

What is also generally lacking in the prior art is a means to implement a complex, multi-level security sys- 

55 tern in a computer network in which computer processes are mobile. One type of security which is afforded 
by the present invention, and which is not suggested by the prior art, is the security afforded by places. As 
discussed in greater detail below, places, by granting or denying ingress to various agents, provide various 
levels of security and several places can be configured to provide multi-level, hierarchical security. 
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To assist in the understanding and visualization of the various aspects and embodiments of the present 
invention, various representational and relational conventions are used in the drawings. Representational and 
relational conventions used herein are represented in Figures 5A, 5B and 5C. Computer system 120A (Figure 
5A) is executing place 220A. place 220% place 220Y, agent 150A, agent 1 SOX and agent 1 SOY. Computer sys- 

5 tern 120Aalso contains objects 140A, 140B and 140X in a memory, e.g., mass memory or main memory (nei- 
ther shown), of computer system 1 20A. Agent 1 50A and 1 SOX occupy place 220A; place 220Y occupies place 
220X; and agent 150Y occupies place 220Y. Agent ISOAowns objects 140Aand 140B, and agent 150X owns 
object 140X. The relationships of occupancy and ownership are discussed in greater detail below. Briefly, oc- 
cupancy of places provides various levels and types of security, and ownership determines which objects travel 

10 with an agent which performs operation "go". 

Figure SB is an alternative and equivalent representation of the various relationships represented in, and 
described above with respect to, Figure 5A. While Figure 5A accurately represents, e.g.. that agent 150X oc- 
cupies place 220Aand contains object 140X. the form of Figure 5A is less suitable for representing more com- 
plex relationships. Therefore, the tree structure of Figure SB is used in the drawings to represent more complex 

15 relationships in illustrating the various computer instructions of various embodiments of the present invention. 

The tree structure of Figure SB should not be confused with the class hierarchy tree which is shown in 
part in Figure SC. Figure 5C represents the class relationships of various items represented in Figures 5A and 
SB. Objects 140A, 140B and 140X are members of class "Object" which is represented by class object 520. 
Membership in a class is discussed in greater detail in the Glossary of Terms above and is represented by a 

20 dashed line between the class and the object which is a member of the class. Class object 522 represents 
class "Process", which is a subclass of class "Object". Places 220X, 220Y and 220A are members of class 
"Place", which is a subclass of class "Process" and is represented by class object 524. Agents 150A, 150X 
and 150Y are members of class "Agent", which is a subclass of class "Process" and is represented by class 
object 526. Thus, places 220X, 220Y and 220A and agents 150A. 150X and 150Y are all members of class 

25 "Process" and are therefore computer processes. Objects 140A, 140B and 140X are not members of class 
"Process" and are therefore not computer processes. 

When an agent is transported from place to place, objects owned by the agent are transported with the 
agent from place to place. However, transporting an object can consume considerable resources if the object 
is large. In general, time in transporting an agent containing objects from a first place executing within ajMrst 

30 computer system to a second place executing within a second computer system is substantially reduceji by 
eliminating transportation of objects already at the second place. This is easily demonstrated by considering 
a simple example. Agent 1 50A (Figure 6A) is executing within computer system 1 20Aand occupies place 220A 
which is also executing within computer system 120A. Agent ISOAowns objects 140A. 140B and 140C. In. this 
embodiment, object 140B has digest 622. Digest 622 indicates that object 140B is interchangeable and. that 

35 any object having a digest equal to digest 622 can be substituted for object 140B. 

Place 220B owns, and therefore contains, objects 624 and 626. Object 624 has digest 628. A process "con- 
tains" all the objects owned by the process and the classes of which the process and the objects owned by 
the process are members. 

In performance of operation "go", as indicated above, agent ISOAand all objects contained by agent 150A 

40 are represented in a standardized form. However, object 140B is not included in the standardized form of agent 
1 50A. Instead, a copy of digest 622, i.e., digest 622-C (Figure 6B), is included in the standardized form of agent 
1 50A. Agent 1 50A, objects 140Aand 140C, and digest 622-C are transported over communications link 102AB, 
in the direction of arrow A, to computer system 1 20B. Object 1 40B is held within computer system 1 20A at least 
until it is determined that an equivalent interchangeable object is found within computer system 120B. 

45 At computer system 1 20B (Figure 6C), agent 150A, objects HOAand HOC, and digest 622-C are decoded. 

In decoding agent 150A. computer system 120B recognizes digest 622-C and determines whether an object 
with an equivalent digest occupies place 220B. Object 624 occupying place 220B has digest 628 which is equal 
to digest 622, and is therefore equal to digest 622-C. Since digest 628 is equal to digest 622, objects 140B 
and 624 are interchangeable. Therefore, in decoding agent 150A. a copy, e.g., object 624-C, is made of object 

so 624 and substituted within agent 150A for interchangeable object 140B. Agent 150A therefore owns object 624- 
C, which is a copy of object 624. in lieu of object 140B. Thus, transportation of object 140B to place 220B is 
obviated. Since an equivalent interchangeable object is found within computer system 120B, object 140B can 
be deleted from computer system 120A. Of course, there are situations in which an equivalent interchanged 
object is not found on computer system 120B. In such a situation, object 140B (Figure 6B) is retrieved from 

55 computer 120A as described more completely below. 

An agent, occupying a first place, is capable of creating one or more clone processes of the agent and 
transporting each clone process to a respective place. Thus, in effect, an agent is capable of traveling to and 
occupying several places simultaneously. Of course, it is not a single agent that travels simultaneously but 
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rather the clones of the agent. 

To travel to and occupy several places simultaneously, an agent issues an instruction which creates mul- 
tiple clones of the agent and causes each clone to travel to a respective place. Each clone is an agent, and, 
at the time of a clone's creation, the clone is identical to the original agent, and therefore includes an execution 

5 state identical to that of the original agent. 

For example, agent 1 50A. which occupies place 220A in computer 1 20A (Figure 7A), issues an instruction 
to computer system 1 20A which creates clones of agent 150A and transports the clones to occupy one or more 
places, e.g., place 220B in computer system 120B and place 220C in computer system 120C, which are spe- 
cified in the instruction issued. The instruction is called operation "send", and the issuance of the instruction 

10 by agent 150A is called herein performance of operation "send" by agent 150A. Performance of operation 
"send" by agent 150Aas represented in Figures 7A, 7B, 7C and 7D is controlled, in this embodiment, by two 
tickets (not shown) within agent 1 50A. The two tickets control the transportation of respective clones and spec- 
ify places 220B and 220C as the places to which respective clones of agent 150A are to be transported. 
Agents 150A-1 and 150A-2 (Figure 7B) are clones formed from agent 150A, and are identical to agent 

15 150A except that agents 150A-1 and 150A-2 do not occupy place 220A. As described above, even the exe- 
cution states of agents 150A-1 and 150A-2 are initially identical to the execution state of agent 150A. Agents 
1 50A-1 and 1 50A-2 travel along intercomputer communications link 1 20ABC (Figure 7C), as described in great- 
er detail below, to respective places 220B and 220C. 

After performance of operation "send" by agent 150A (Figure 7D), agent 150A continues to occupy place 

20 220A. Agent 150A-1 occupies place 220B, and agent 150A-2 occupies place 220C. 

Space in computer system 120Aand time in transporting clones of agent 150Aare saved by deferring com- 
plete cloning of an agent 1 50A so long as the travel path of one clone coincides with the travel path of another 
clone, i.e., at least two clones have some initial portion of their journey that is coextensive. For example, in 
Figure 7E, both clones of agent 1 50A must pass through computer system 1 20D to reach respective destination 

25 places 220B and 220C. Therefore, only a single clone of agent 150A, namely, agent 150A-1, is transported to 
computer system 120D. A second clone of agent 150A, namely, agent 150A-2, is formed in computer system 
120D from agent 150A-1. Agents 150A-1 and 150A-2 are then transported to respective destination places 
220B and 220C. Thus, only a single clone of agent 1 50A is formed in computer system 1 20A and only a single 
clone is transported to computer system 120D saving space in computer system 120Aand time in transporting 

30 agents 150A-1 and 150A-2 to their respective destinations. 

Two agents exchange information by participating in a meeting between the two agents. In such a meeting, 
each agent is provided with a reference to the other agent. As discussed below, a first agent, which possesses 
a reference to a second agent, (i) can direct the second agent to take specific actions in accordance with in- 
structions contained with the second agent and (ii) can transfer data to and receive data from the second agent. 

35 In one aspect of the present invention, an agent is prevented from interfering with other agents by requiring 
that no agent be given a reference to a second agent unless the second agent is given a reference to the first- 
mentioned agent. In that way, no agent can gain access to a second agent without granting reciprocal access. 

A first agent, occupying a place, can initiate a meeting with a second agent occupying that place. During 
such a meeting, the first agent can transfer objects to and receive objects from the second agent, and the 

40 second agent can transfer objects to and receive objects from the first agent. 

A subclass of class "Place" (Figure 5C) is class "Meeting Place" (not shown). In the illustrative example 
of Figures 8A-8F, place 220B is a member of class "Meeting Place" and is therefore a meeting place. Therefore, 
place 220B is sometimes referred to herein as "meeting place 220B'\ Meeting place 220B (Figure 8A), which 
is executing in computer system 120B, provides a means for agents 150A and 150B, which occupy meeting 

45 place 220B, to communicate and share information in a meeting as indicated by arrows A and B. Petition 3106 
within agent 150A defines and controls the meeting between agents 150Aand 150B. 

A meeting between agent 150Aand 150B is arranged as illustrated by Figures 8B-8F. Agent 150A (Figure 
8B) issues a first computer instruction, represented by arrow 851, directing meeting place 220B to arrange a 
meeting between agents 150Aand 150B. The first instruction includes petition 3106, which controls the meet- 

50 ing, and which specifies that agent 150A wants to meet with agent 150B. On behalf of meeting place 220B 
(Figure 8C), the engine issues a second computer instruction, represented by arrow 852, which notifies agent 
1 50B that agent 1 50A has issued the first computer instruction, and which causes execution of a number of 
computer instructions within agent 150B to determine whether a meeting between agents 150Aand 150B is 
acceptable. 

55 Upon determination that the meeting between agents 150A and 150B is acceptable (Figure 8D), agent 

150B issues a reply, represented by arrow 853, to the second computer instruction, directing the engine, on 
behalf of meeting place 220B, to proceed in arranging the meeting between agents 1 50A and 1 50B. On behalf 
of meeting place 220B (Figure 8E), the engine conveys to agent 150Aa reference to agent 150B. the convey- 
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ance being represented by arrow 854A, and conveys to agent 1 SOB a reference to agent 1 50A, the conveyance 
being represented by arrow 854B. Agent 150A (Figure 8F) interacts with agent 150B using the reference to 
agent 150B, the reference being represented by arrow 855A. and agent 150B interacts with agent 150A using 
the reference to agent 150A, the reference being represented by arrow 855B. 

5 Two agents cannot participate in a meeting together unless the two agents occupy the same place. A hi- 

erarchy of places provides users of the present invention a mechanism to provide varying levels and types of 
access and security to various agents. The benefit of various levels and types of access and security is dem- 
onstrated by the illustrative example of Figures 9A-9E, 

Figure 9A shows a building 902 having floors 902-1 , 902-2, 902-3, 902-4 and 902-5. Floor 902-3 is a place 

w within the place of building 902 and is therefore a subplace of building 902. Figure 9B shows floor 902-3 having 
rooms 902-3-1, 902-3-2, 902-3-3, and 902-3-4. Room 902-3-2 is a place within the place of floor 902-3 and 
is therefore a subplace of floor 902-3. 

The organization of building 902 lends itself to hierarchical security. For example, building 902 can be re- 
stricted to allow only people of a first level of security, e.g., military personnel, to enter. Floor 902-3 can be 

15 further restricted to allow only people of a second (higher) level of security, e.g., naval personnel, to enter. 
Room 902-3-2 can be still further restricted to allow only people of a third (still higher) level of security, e.g., 
naval officers, to enter. Floor 902-4 can be restricted independently of floor 902-3, e.g., to allow only air force 
personnel to enter. 

The engine in computer system 120X (Figure 9C) is executing places 220X1 and 220X2. Place 220X1 can 

20 represent, for example, building 902. Places 220X1-1 and 220X1-2, which represent, for example, floors 902- 
4 and 902-3, occupy place 220X1 (Figure 9D) and are therefore subplaces of place 220X1. Conversely, place 
220X1 is a superplace of places 220X1-1 and 220X1-2. Place 220X1-2-1 , which represents, for example, room 
902-3-1 , occupies place 220X1-2 (Figure 9E). Place 220X1-2-1 is therefore a subplace of place 220X1-2. and 
place 220X1-2 is a superplace of place 220X1-2-1. 

25 In one embodiment of the present invention, two agents can only meet "face-to-face", i.e., when both 

agents occupy the same place. As used herein, an agent "occupies" one place only and does not simultane- 
ously occupy subplaces or superplaces of the place. For example, an agent occupying place 220X1-2 does 
not simultaneously occupy place 220X1 or place 220X1-2-1 . Just as a first person in building 902 (Figure 9A) 
cannot communicate face-to-face with a second person on floor 902-3 unless the first person is also on floor 

30 9 02-3, an agent occupying place 220X1 (Figure 9D) cannot communicate with an agent occupying place 
220X1-2. As a first person on floor 902-3 (Figure 9B) cannot communicate face-to-face with a second person 
in room 902-3-2 unless the first person is also in room 902-3-2, an agent occupying place 220X1-2 (Figure 
9E) cannot communicate with an agent occupying place 220X1-2-1. a 

Such a place hierarchy enables a user of the present invention to restrict access to place 220X1 . to further 

35 restrict access to place 220X1-2 and to restrict access to place 220X1 -2-1 further still. Additionally, the security 
hierarchy implemented is not necessarily directly related to the place hierarchy implemented. For example, 
access to place 220X1-2 can be more restrictive than access to a subplace of place 220X1-2. such as place 
220X1-2-1. The restriction of access to a place is described in greater detail below. Thus, the place hierarchy 
enables a user of the present invention to construct sophisticated security hierarchies in which various agents 

40 are given various levels of access to other agents which occupy certain places, subplaces of those places, 
and subplaces of those subplaces. 

To describe further details of the novel processes described above, a better understanding of the structure 
of the computer systems described above is required. In the embodiment shown in Figure 10, three computer 
systems are connected to form a computer network 100. Computer system 120A includes CPU 11 OA, network 

45 communications hardware 104A, and memory 117A. Input and output modules corresponding to input module 
1 2 and output module 1 4 of Figure 1 are omitted for clarity. Additionally, mass memory 1 7A and main memory 
17B of Figure 1 are combined to form memory 11 7A. Network communications hardware 104Acan be any de- 
vice which enables CPU 11 OA to propagate signals across and to receive and interpret signals from the net- 
work. 

50 Within memory 117Aare a number of computer processes operating concurrently within CPU 110A. Net- 

work manager 1 30A is a computer process which coordinates data transmission between the various computer 
systems of the computer network. Operating system 131 A is a computer process which coordinates the oper- 
ation of the various components and resources of computer system 1 20A. For example, operating system 1 31 A 
coordinates the use of components CPU 11 OA. memory 117A and I/O modules (not shown in Figure 10. see 

55 Figure 1 ). Engine 1 32A is a computer process which interprets computer instructions of an object-oriented com- 
puter instruction set of this invention and processes information in the form of objects defined in that object- 
oriented computer instruction set. For example, engine 1 32A effectuates concurrent execution of place 220A 
(Figure 4A) and agent 1 50A, both of which are processes constructed of the object-oriented computer instruc- 
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tion set of the present invention. Engine 132A is not shown in Figure 4A. 

In addition to these processes operating within memory 117A(Figure 10) of computer system 120A, there 
are typically one or more processes which are user applications, e.g. user application 133A. User application 
1 33A can request of engine 1 32A the creation of and/or manipulation of objects defined within the object-ori- 
5 ented instruction set interpreted by engine 132A. 

Computer systems 1 20B and 1 20C are configured similarly to computer system 1 20A. However, while the 
general structure of computer systems 120A, 120B and 120C are similar, computer systems 120A, 120B and 
120C can be otherwise heterogeneous. 

The computer systems of computer network 100 are connected such that an agent process can be trans- 
10 ported from one computer system to another. Computer systems 1 20A, 1 20B and 1 20C are connected to form 
a computer network by coupling the respective network communications hardware 104A, 104B and 104C by 
means of communications links 102AB, 102BC and 102AC. Communications links 102AB, 102BCand 102AC 
can be any means by which data can be conveyed from one network communications hardware, e.g., network 
communications hardware 104Ato another, e.g., network communications hardware 104B. For example, net- 
15 work communications link 102AB can be the public switched telephone network, in which case network com- 
munications hardware 104Aand 104B are modems and network managers 130Aand 130B are capable of is- 
suing commands to network communications hardware 104Aand 104B, respectively, to establish and utilize 
communications via communications link 102AB i.e., the public switched telephone network. 

Objects constructed of the object-oriented computer instruction set are executed by an engine, e.g., en- 
20 gine 132A (Figure 11A). Engine 132A has a communication infrastructure 132A-CI, a program portion 132A- 
P, and a data portion 132A-D. Data representing the state of the various objects executed by engine 132A, 
e.g.. object 140A, are stored in data portion 132A-D of engine 132A. Data portion 132A-D of engine 132A is 
memory space within memory 1 1 7A (Figure 1 0) reserved as work space for engine 1 32A and is generally in- 
accessible from the perspective of other processes on computer system 120A, e.g. operating system 131A 
25 and user application 133A. 

As discussed above, an engine effectuates execution of processes and objects. Program portion 132A- 
P (Figure 11A) of engine 132A includes computer instructions which effectuate execution of the objects rep- 
resented in data portion 1 32A-D. The computer instructions which are combined to form program portion 1 32A- 
P can be of a known computer language. For example, the computer software in Appendix G is a program por- 
30 tion of an engine constructed in accordance with the principles of the present invention and is constructed in 
accordance with the C++ programming language. 

Communication infrastructure 132A-C! of engine 132A includes computer instructions which transport 
data between engines dispersed throughout network 100. Many aspects of the communication infrastructure 
of an engine are described in greater detail in Appendix D. which is a part of this disclosure. 
35 Figure 11 B is an alternative and equivalent representation of the computer network of Figure 11 A. 

As indicated by Figure 1 1 A. engine 1 32B of computer system 1 20B is configured in a manner that is directly 
analogous to the configuration of engine 132A. 

Objects within the Network 

40 

As explained more completely below, places 220A and 220B (Figure 4 A), agent 150A, ticket 1306, etc. 
are defined using "objects" according to the principles of this invention. As stated above, objects, which are 
formed according to the computer instruction set interpreted by engines 132Aand 132B and which are inter- 
preted by engine 1 32A, are stored in data portion 1 32A-D (Figure 1 1 A). For example, object 1 40A in data portion 
45 132A-D is formed according to the computer instruction set ir*--roreted by engines 132Aand 132B and is in- 
terpreted by engine 132A. 

Brief Overview of the Computer Instruction Set of the Present Invention 

50 Each of the novel processes of this invention, and the features needed to define and support the proc- 

esses, are defined by a set of computer instructions that are interpreted by an engine of this invention. The 
computer instructions of the present invention are object-oriented. Therefore, data in the present invention, 
e.g.. data which represent agent 150A, are organized into objects, each of which has an internal state and an 
external behavior. An object's properties define the object's internal state and the object's features define the 

55 object's external behavior (see Glossary of Terms above). Each object is an instance of a respective one of a 
number of classes. 

According to the principles of this invention, all classes defined in the computer instruction set, except for 
mix-in classes which are described below, are subclasses of a class "Object", which is described more com- 
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pletely in Appendix A. Thus, each class that is described herein and which is not a mix-in class inherits the 
features and properties of class "Object". 

In one embodiment, limited multiple inheritance is implemented using mix-in classes. "Mix-ins" or "mix-in 
classes" are classes which are not subclasses of class "Object". Examples of mix-in classes, which are de- 

5 scribed below and in Appendix A, include mix-in classes "Executed". "Named" and "Referenced". A non-mix- 
in class, alternatively called a "flavor" or a "flavor class", can be the immediate subclass of at most one flavor, 
but can be the immediate subclass of zero or more mix-in classes. A mix-in class can be the immediate subclass 
of no class or of another mix-in class. Unless otherwise stated, a class is a flavor. No cycles in class hierarchy 
are permitted; i.e., no class is permitted to be both a subclass and a superclass of another class. 

w The use of mix-in classes allows features and properties to be defined once and used across a broad va- 

riety of classes. For example, mix-in class "Ordered" defines operations for determining the relative order of 
two objects. Flavor classes "Association". "Citation". "List". "Identifier", "Pattern". "Permit", "Bit", "Boolean", 
"Character". "Number", "Octet" and "Time" inherit from mix-in class "Ordered". Thus, associations, citations, 
lists, identifiers, patterns, permits, bits, booleans, characters, numbers, octets and times have an order rel- 

15 ative to other members of the same class. For example, in the case of numbers, the number two is "after" the 
number one and is "before" the number three. 

The principal class of objects in the present invention is the class of processes. As described above, proc- 
esses are either (i) places which are occupied by other processes, or (ii) agents which can (a) transport them- 
selves from a first place, terminating occupancy of the first place, to occupy a second place and (b) interact 

20 with other agents occupying the same place. 

Agent 150A(Figure 11 A) is a process formed in accordance with the computer instruction set of the present 
invention whose execution is carried out by engine 132A. Agent 150A can (i) examine and modify itself, (ii) 
transport itself from a first place in network 1 00 (Figure 1 0) to a second place, and (iii) interact with other agents 
which occupy the second place. 

25 Herein, a process is described as performing an operation that consumes arguments and produces zero 

or one result. However, a process, in and of itself, is an object that includes a collection of instructions, which 
are selected from the instructions described more completely below, and which is interpreted by an engine, 
e.g., engine 132A which is executing in CPU 110A. The performance of an operation by a process, or any other 
object of the disclosed instruction set, is in actuality the selection of and interpreting of a particular group of 

30 the instructions included in the process or object. Interpreting the instructions of a process by an engine is 
herein alternatively called "interpreting the process". Thus, when agent 150A performs an operation, agent 
150A provides instructions to engine 132A which in turn interprets the instructions and directs CPU 110Ato 
carry out appropriate tasks effectuating performance of the operation by agent 1 50A. The interaction between 
a process and an engine is described more completely below. 

35 An important aspect of the present invention is that the set of computer instructions described more com- 

pletely below is implemented uniformly by the respective computer systems of network 100 (Figure 10). Com- 
puter systems 120A. 120B and 120C can use completely different and incompatible data structures, memory 
configurations, CPUs and operating systems. But, since an agent is capable of transporting itself to and from 
any of computer systems 120A. 120B and 120C. it is important that each computer system implement the set 

40 of computer instructions of the present invention in a standardized fashion. As long as the computer instruc- 
tions are uniformly implemented, computer systems 120A. 120B and 120C can be otherwise incompatible. 
Therefore, agents can travel freely among the computer systems of a heterogeneous, as well as a homoge- 
neous, computer network. 

Typically, prior art systems either required that processes travel only within homogeneous networks or that 
45 processes be specifically designed to execute computer instructions which were compatible with the computer 
system within which the process was executing. In the latter case, processes were configured for the particular 
system requirements of the computer system on which execution of the process began and for the particular 
system requirements of any computer systems to which the process was intended to travel. Thus, as the com- 
puter instructions of an agent of the present invention can execute on any computer system of a heterogeneous 
50 network, the present invention represents a substantial improvement over the prior art. 

Agents 

As discussed above, the behavior of an agent is dependent in part on the internal state of the agent. There- 
55 fore, prior to considering the external behavior of an agent in a network, several aspects of the internal state 
of an agent are briefly discussed. Each agent is a member of class "Agent". 

It should be noted that no agents are instances of class "Agent," as class "Agent" is abstract. Class "Agent" 
is abstract as no implementation for operation "live" is defined or inherited by class "Agent". As discussed below 
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and in Appendix A in greater detail, operation "live" defines the steps that are performed by a process, i.e., an 
agent or a place, upon creation of the process. These steps are collectively called the "central procedure" of 
the process. A central procedure for either agents or places is not provided as users of the present invention 
design and provide central procedures for agents and places to suit the particular needs of each user. Thus, 
5 users of the present invention create concrete subclasses of class "Agent" and therein provide implementations 
for operation "live". 

Class "Agent" is a subclass of class "Process". (See Figure 5.) Class "Process" is a subclass of class "Ob- 
ject" and also inherits from mix-in class "Named". Class "Object" inherits from mix-in class "Referenced". An 
agent possesses the following attributes: (i) attributes "class" and "size" inherited from superclass "Object"; 
10 (ii) attribute "isProtected" inherited from mix-in class "Referenced"; (iii) attribute "name" inherited from mix-in 
class "Named"; and (iv) attributes "brand", "permit" and "privateClasses" inherited from superclass "Process". 
Class "Agent" defines no attributes. Each of the above-mentioned attributes and classes is discussed in more 
detail in Appendix A. 

Diagram 1270 (Figure 12) illustrates the class relations of the classes of which agent 150A is a member. 
15 Agent 1 50A is a member of class "Agent" as agent 1 50A is shown to be contained within domain 1 272 which 
represents class "Agent". Since class "Agent" is abstract, agent 150A is also a member of one or more sub- 
classes (not shown) of class "Agent". 

Domain 1272 is completely contained within domain 1274 which represents class "Process". Agent 150A 
therefore inherits attributes "brand", "permit" and "privateClasses", which are defined by class "Process". Ad- 
20 ditionally. all members of class "Agent" are also members of class "Process". Thus, as described above, class 
"Agent" is a subclass of class "Process". 

Domain 1274 is completely contained within domain 1276 which represents class "Object". Agent 150A 
therefore inherits attributes "class" and "size" which are defined by class "Object". Additionally, all members 
of class "Process", including members of class "Agent", are also members of class "Object". Thus, as described 
25 above, class "Process" is a subclass of class "Object". 

Domain 1274 representing class "Process" is contained within domain 1278, which represents class 
"Named". Connection 1278A shows that domain 1274 is contained within domain 1278 while accurately rep- 
resenting that domain 1 276. representing class "Object", is not contained within domain 1 278 and that domain 
1278 is not contained within domain 1276. Class "Named", represented by domain 1278. is a mix-in class. As 
30 domain 1274 is contained within domain 1278, agent 150A is contained within domain 1278 and is therefc.e 
a member of mix-in class "Named". Mix-in class "Named" defines attribute "name" which is included in agent 
150A. 

Domain 1280 which represents mix-in class "Referenced" contains domain 1276. which represents class 
"Object", as indicated by connection 1280A. As domain 1276 is contained within domain 1280. agent 150Ais 
35 contained within domain 1280 and is therefore a member of mix-in class "Referenced". Mix-in class "Refer- 
enced" defines attribute "isProtected" which is included in agent 150A. 

As every flavor of the disclosed embodiment of the present invention is a subclass of class "Object", every 
flavor is also a subclass of mix-in class "Referenced". Thus, it is not necessary to separate the features of class 
"Referenced" from the features of class "Object". However, the features of mix-in class "Referenced" are sepa- 
40 rated from the features of class "Object" to aid conceptualization and understanding of the present invention. 

As discussed above in the Glossary of Terms, objects are identified within the disclosed computer instruc- 
tion set by references. As discussed in greater detail below, in directing an object to perform an operation, the 
object is identified by a reference. Features defined by mix-in class "Referenced" operate on the reference 
which identifies the object. For example, attribute "isProtected" determines whether the reference to the object, 
45 and not the object itself, is protected. Features defined by class "Object" operate on the object identified by 
the reference. For example, attribute "class" determines of which class the object is an instance. 

It should be noted that no attribute is defined which provides information regarding the place occupied by 
agent 1 50A (Figure 1 2). However, the place occupied by agent 1 50A is maintained as a property of agent 1 50A. 
Agent 150A can determine which place agent 150A occupies by execution of the "here" selector. The execution 
50 of selectors, and in particular the "here" selector, is discussed in greater detail in Appendix A. The property 
which is the place occupied by agent 150Ais defined by class "Process". Thus, any process, i.e., either a place 
or an agent, includes a property which is the place occupied by the process. 

While the only class disclosed herein and in Appendix A which is an immediate subclass of mix-in class 
"Named" is class "Process", subclasses of mix-in class "Named", which are not subclasses of class "Process", 
55 are defined by users of the present invention using the instructions disclosed herein and in Appendix A. There- 
fore, class "Named" is a mix-in class. 



22 



EP 0 634 719 A2 



Agents as Processes 

Associated with every process, both agents and places, is a central procedure which defines the primary 
behavior of the process as discussed above. The central procedure of a process is the method which imple- 
5 ments an operation "live" as performed by the process. An engine initiates processing of a process by causing 
the process to perform operation "live", thereby causing execution of the process's central procedure. The pro- 
vision of a method for an operation is discussed in greater detail below. When a process completes perfor- 
mance of operation "live", either successfully or otherwise, the process is terminated. The termination of a proc- 
ess is discussed in section 2.4.11 of Appendix A and that discussion is incorporated herein by reference. 

10 

Mobility of Agents: Operation "Go " 

As discussed above, an agent travels from one place to another by performance of operation "go". Oper- 
ation "go" is discussed in the context of the illustrative example of Figures 15A-15E. To travel from place 220A 
15 to place 220B, agent 1 50A (Figure 1 5A) performs operation "go". Figure 1 5A shows the state of network 1 500 
prior to performance of operation "go" by agent 150A. 

Agent 150Aowns objects 140Aand 140B and occupies place 220Ain engine 132A. Thus, agent 150Aand 
place 220Aare processes which are simultaneously interpreted by engine 132A. In other words, place 220A 
and agent 150Aare simultaneously performing operation "live". Engine 132B interprets place 220B and agent 
20 1 SOB. Agent 1 50B occupies place 220B. 

Communication infrastructure 132A-CI of engine 132A is connected to communication infrastructure 
132Z-CI of engine 132Z by communications link 102AZ. Engine 132Z interprets place 220Z. Communication 
rastructure 132Z-CI is also connected to communication infrastructure 132B-CI of engine 132B by commu- 
nications link 102ZB. While in this embodiment only three computer systems are illustrated in network 1500, 
25 the number of computer systems in network 1500 is an arbitrary number. Hence, the computer systems illu- 
strated in Figure 15Aare illustrative of the principles of the invention and are not intended to limit the invention 
to the particular network illustrated. 

Performance of operation "go" by agent 150A, in this embodiment, requires transportation of agent 150A 
from engine 132A through engine 132Z to engine 132B. Hence, operation "go" requires action on the part of 
30 engine 1 32A. i.e., the source engine, engine 1 32Z. i.e. the transit engine, and engine 1 32B. i.e., the destination 
engine. 

Operation "Go" as Performed by the Engine Processing the Source Place 

35 Figure 13A shows a portion of the internal state, including a portion of the execution state, of agent 150A 

immediately prior to performance of operation "go" by agent 150A. The execution state of a process is descri- 
bed in greater detail below. Stack 1304 is a part of the execution state of agent 150A. Stack 1304 contains, at 
top "T", ticket 1306. Ticket 1306 is described more completely below. Arguments consumed by performance 
of operation "go" are popped from stack 1304 and stack 1304 is therefore the "current stack" in the context of 

40 operation "go". Place 220A is a property of agent 1 50A. indicating that agent 1 50A occupies place 220A. 

Figure 1 3B shows a portion of the internal state, including a portion of the execution state, of agent 1 50A 
immediately following performance of operation "go" by agent 150A. Figure 13B is described in greater detail 
below. 

Logic flow diagram 1 400 (Figure 14A) illustrates operation "go" as carried out by engine 1 32A(Figure 1 5A). 

45 Engine 1 32A is the source engine as agent 1 50A is executing within engine 1 32A when performance of oper- 
ation "go" is initiated. The steps of logic flow diagram 1400 (Figure 14A) are discussed in the context of the 
trip from place 220A (Figure 15A) to place 220B taken by agent 150A. 

In performance of operation "go" by agent 1 50A. engine 1 32A (Figure 1 5A) determines whether agent 1 50A 
is the agent requesting performance of operation "go" in an access test step 1402 (Figure 14A). If operation 

50 "go" is requested by an object other than agent 1 50A (Figure 1 5A), processing transfers from access test step 
1402 (Figure 14A)to terminal step 1404 in which an exception of class "Process Not Current" is thrown causing 
operation "go" to fail. If. however, operation "go" is requested by agent 150A (Figure 15A), processing transfers 
from access test step 1402 (Figure 14A) to a "canGo" test step 1406. 

In "canGo" test step 1406, engine 132A (Figure 15A) determines whether agent 150Ais permitted to per- 

55 form operation "go". In "canGo" test step 1406, engine 132A (Figure 15A), queries attribute "permit" of agent 
1 50A. Attribute "permit" as discussed above, is one of a plurality of attributes of agent 1 50A, The various at- 
tributes of agent 150Aare described in greater detail in Appendix A in conjunction with class "Process". The 
query of attribute "permit" of agent 150A produces property "permit" of agent 150A. Specifically, permit 1612 
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(Figure 16) is property "permit" of agent 150A and is therefore produced by querying attribute "permit" of agent 
150A. In this embodiment, property "permit" is one of a number of properties of agent 150A. 

Permit 1612 (Figure 17) includes, among several properties which are described in greater detail in Ap- 
pendix A, properties "charges", "canGo", and "age" which are integer 1702, boolean 1704, and integer 1706, 
5 respectively. A boolean is an object having one of only two possible values: "true" or "false". In "canGo" test 
step 1 406 (Figure 1 4A), engine 1 32A (Figure 1 5A) queries att ribute "canGo" of permit 1612 (Figure 1 7), thereby 
producing boolean 1704 which is property "canGo" of permit 1612, and compares boolean 1704 to "true". 

If boolean 1704 has a value of "false", processing transfers from "canGo" test step 1406 (Figure 14A) to 
terminal step 1408. Agent 150A is not permitted to travel by performance of operation "go" and the operation 
10 fails and throws an exception that is a member of class "Permit Violated" in terminal step 1408. Exceptions 
and their classification are described more completely in Appendix A. 

Otherwise, if boolean 1704 (Figure 17) has a value of "true", processing transfers from "canGo" test step 
1406 (Figure 14A) to an effectuate move step 1410. Effectuate move step 1410 is described in greater detail 
below in conjunction with Figure 14B. Processing transfers from effectuate move step 1410 (Figure 14A) to 
15 terminal step 1412 in which operation "go", to the extent engine 132A is involved, completes successfully. 

Effectuate move step 1410, which is performed by engine 132A (Figure 15A) as described above, is rep- 
resented by logic flow diagram 1410 (Figure 14B). In the first step of logic flow diagram 141 0, i.e., route agent 
step 1414, engine 132A(Figure 15A) selects an engine to use in transporting agent 150A to the trip destination, 
i.e., a "transfer destination". As used herein, the transfer destination is the next engine used in the trip and 
20 should not be confused with the "trip destination". Ticket 1306 (Figure 13A) defines a place as the destination 
of a trip; therefore, the "trip destination" is a place. I n the course of the trip defined by ticket 1 306 (Figure 1 3A), 
agent 150A (Figure 15A) is transferred from one engine to another. Therefore, a "transfer destination" is an 
engine. In general, a trip can require several transfers of an agent before the agent reaches an engine which 
contains a trip destination. 

25 Instep 1414 (Figure 14B), a way object, i.e., a member of class "Way", which defines a transfer destination 

is produced. The transfer destination can be, for example, (i) the engine which currently contains agent 1 50A, 
i.e., engine 132A, in which case agent 150A is not transferred, (ii) another engine in the region which contains 
engine 1 32A, or (iii) an engine in another region. In either of possibilities (ii) or (iii), agent 1 50A is transferred 
to the transfer destination as described below. 

30 The term "region" is defined above in the Glossary of Terms. The grouping of engines into regions is sig- 

nificant in the routing of an agent as each engine typically contains more detailed information regarding other 
engines within the same region than engines of other regions. This is true because engines of a single region 
are configured by a single person or organization, which is therefore called the "provider" of the region. There- 
fore, each engine of a region can be given detailed information regarding other engines of the region as all 

35 such engines are provided by a single provider. 

The grouping of engines into regions is helpful in routing agents in large and complex networks. When an 
agent travels between regions, it is not imperative that the source engine contain any information regarding 
the transfer destination engine. It is sufficient that the source encsne can determine to which region the agent 
is traveling and can transfer the agent to an engine in that region. Once transferred to an engine in the region 

40 containing the place that is the trip destination, the agent can be more easily routed to an engine containing 
that place. 

Logic flow diagram 1414 (Figure 14C) shows the steps carried out in route agent step 1414 (Figure 14B) 
and is discussed below in greater detail. 

Processing transfers from route agent step 1414 to an isolate agent step 1416 where agent 150A (Figure 

45 1 5A) is isolated. Isolation of a process is described in greater detail in Appendix A and that discussion is incor- 
porated herein by reference. Briefly, agent 150A is isolated (i) by voiding all references within agent 150Ato 
other processes, and to objects owned by other processes, and (ii) by voiding within all other processes ref- 
erences to agent 150A and to objects owned by agent 150A. Processing transfers from isolate agent step 1416 
(Figure 14B) to exiting step 1418. 

50 In exiting step 1418, place 220A (Figure 15A) notes the departure of agent 150A by performing operation 

"exiting" at the request of engine 132A. Operation "exiting" is described below in greater detail. Processing 
transfers from exiting step 1418 to a next hop is here test step 1420. 

In next hop is here test step 1420, engine 132A (Figure 15A) compares the transfer destination determined 
in route agent step 1414 (Figure 14B) to the current engine, i.e., engine 132A (Figure 15A). If the transfer des- 

55 tination is the current engine, i.e.. engine 132A, processing transfers from next hop is here teststep 1420 (Fig- 
ure 14B) to deliver agent step 1422. In the illustrative example of Figures 15A-15E, agent 150A is transferred 
to engine 132Z, as discussed below; thus, the transfer destination is not the current engine, i.e., engine 132A, 
and processing does not transfer to deliver agent step 1422 (Figure 14B). However, deliver agent step 1422 
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and the steps which follow are described for completeness. 

In deliver agent step 1422, agent 150A (Figure 15A) is delivered to a place within engine 132A which sat- 
isfies ticket 1306 (Figure 13A). Deliver agent step 1422 (Figure 14B) is represented by logic flow diagram 1422 
(Figure 14E) and is discussed in greater detail below. Processing transfers from deliver agent step 1422 (Figure 

5 14B) to a first exception test step 1424 in which engine 132A(Figure 15A) determines whether delivery of agent 
150A threw an exception. If no exception is thrown in deliver agent step 1422 (Figure 14B), processing transfers 
from first exception test step 1424 to terminal step 1428. Terminal step 1428 completes move step 1410 and 
so processing transfers to terminal step 1412 (Figure 14A) which is described above. 

If, on the other hand, an exception is thrown in deliver agent step 1422 (Figure 14B), processing transfers 

w from first exception test step 1424 to step 1426 in which agent 150A is delivered to purgatory according to 
logic flow diagram 1422 (Figure 14E). Purgatory is a place within each engine and which never denies ingress 
to a process. In entering purgatory, the local permit of agent 150A can be severely restricted. For example, 
property "canGo" of the local permit is set to "true" and properties "canCharge", "canCreate", "canDeny", "can- 
Grant", "can Restart", "canSend" and "canTerminate" are set to "false". Properties "charges" and "age" are set 

15 just large enough that agent 150Acan detect and analyze the exception that sent agent 150A to purgatory, 
and can travel to another place by performance of operation "go". The various properties of a permit are de- 
scribed in greater detail in Appendix A. 

Processing transfers from step 1426 to terminal step 1428 and so effectuate move step 1410 (Figure 14A), 
completes successfully, as described above. 

20 As discussed above, if the transfer destination determined in route agent step 1414 (Figure 14B) is the 

current engine, i.e., engine 132A. processing transfers from next hop is here test step 1420 (Figure 14B) to 
deliver agent step 1422. Conversely, if the transfer destination is not the current engine, processing transfers 
from next hop is here test step 1 420 to a form destination step 1430. In form destination step 1430, a destination 
object which specifies the transfer destination is formed. Processing transfers from form destination step 1 430 

25 to encode agent step 1432. 

In encode agent step 1432, engine 1 32A (Figure 15A) encodes agent 150A according to the encoding rules 
of the Telescript Encoding Rules, included as Appendix B, which is a part of this disclosure and which is incor- 
porated herein by reference in its entirety. Encoding agent 150A results in (i) agent 150A. (ii) all objects owned 
by agent 150A including objects 140Aand 140B and (iii) the classes of which agent 150Aand all objects owned 

30 by agent 1 50A are members being represented in encoded agent 1 50A-E (Figure 1 5B) in a standardized binary 
form. The destination object formed in form destination step 1430 (Figure 14B), i.e.. destination object 150A- 
E-D (Figure 21), is included in encoded agent 150A-E and is discussed in greater detail below. As shown in 
Figure 15B, encoded agent 150A-E is stored in communication infrastructure 132A-CI of engine 132A. Agent 
150A (Figure 15A) is retained by engine 132A until the transfer of encoded agent 150A-E is complete as de- 

35 scribed below in greater detail. 

Processing transfers from encode agent step 1432 to transfer out step 1434. In transfer out step 1434. 
engine 1 32A (Figure 1 5B) initiates transfer of encoded agent 1 50A-E according to the destination object formed 
in form destination step 1430 (Figure 14B). In this example, the destination object specifies engine 132Z (Fig- 
ure 15B) as the transfer destination of encoded agent 150A-E. Encoded agent 150A-E is transferred as ordi- 

40 nary binary data from communications infrastructure 132A-CI. across communications link 102AZ. to com- 
munications infrastructure 132Z-CI of engine 132Z. The transportation of data between communications in- 
frastructures 1 32A-CI and 1 32Z-CI is described in greater detail in Appendix C which is a part of this disclosure 
and Appendix F which is incorporated herein in its entirety by reference. As discussed above, the transfer of 
encoded agent 150A-E is initiated in transfer agent out step 1434. Processing according to logic flow diagram 

45 1410 (Figure 14B) by program portion 132A-P of engine 132A proceeds while the transfer of encoded agent 
150A-E between communications infrastructures 132A-CI and 132Z-CI continues. 

Processing transfers from transfer out step 1434 to a second exception test step 1436 in which engine 
132A determines whether transfer out step 1434 threw an exception, i.e., whether initiation of the transfer of 
encoded agent 150A-E failed. If transfer out step 1434 fails, processing transfers from second exception test 

50 step 1426 in which agent 150A is delivered to purgatory as described above. Conversely, if transfer out step 
1434 succeeds, processing transfers from second exception test step 1436 to step 1438. 

In step 1438, engine 132A (Figure 15B) adds agent 150A to a list of pending transfers. Agent 132A is re- 
tained in the list of pending transfers during the transfer of agent 150A. When the transfer is complete, agent 
150A is removed from the list of pending transfers and discarded by engine 132A. If the permit of agent 150A 

55 expires while agent 150A is still on the list of pending transfers, i.e.. if the actual age of agent 150A reaches 
property "age" of the effective permit of agent 150A, the transfer of encoded agent 150A-E is aborted; agent 
150A is removed from the list of pending transfers; and agent 150A throws an exception of class "Permit Ex- 
pired", thereby failing to perform operation "go" successfully. The "effective permit" of a process is described 
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in greater detail in Appendix A. Processing transfers from step 1438 to terminal step 1428 in which logic flow 
diagram 1410 (Figure 14B), and therefore effectuate move step 1410 (Figure 14A), completes. 

As described above, in route agent step 1414, engine 132A (Figure 15A) determines the transfer destin- 
ation for agent 150A. Logic flow diagram 1414 (Figure 14C) shows the steps carried out in route agent step 
5 1414 (Figure 14B). 

The following discussion of logic flow diagram 1414 (Figures 14C and 14D) considers circumstances be- 
yond the scope of the illustrative example of Figures 1 5A-1 5E. Logic flow diagram 1414 (Figures 1 4C and 1 4D) 
is therefore described independently of the illustrative example of Figures 15A-15E. To provide a framework 
for discussion, however, logic flow diagram 1414 (Figures 14C and 14D) is described in the context of agent 

w 1 50A (Figure 1 5A) performing operation "go" to effectuate a trip which originates in place 220A within engine 
1 32A. The discussion of logic flow diagram 1414 (Figures 1 4C and 1 4D) is not limited to (i) a trip in which agent 
1 50A is transferred to an engine other than engine 1 32A (Figure 1 5A) or (ii) a network in which engines 1 32A, 
1 32Z and 1 32B are of the same region. Furthermore, the following discussion does not limit ticket 1 306 (Figure 
13A), which defines the trip taken by agent 150A (Figure 15A), to either including or excluding specification 

15 of a way, a means, a telename. or a provider. Ticket 1306 (Figure 13A), in the context of logic flow diagram 
1414 (Figures 14C and 14D), can define a trip (i) to a place within engine 132A (Figure 15A), (ii) to a place 
within an engine in the same region as engine 132A, or (iii) to a place within an engine in a region different 
than the region which contains engine 132A. 

Recall that for operation "go", ticket 1306. which is consumed as an argument to operation "go", specifies 

20 the destination and other characteristics of the trip. In logic flow diagram 1414. engine 132A (Figure 15A) in 
test step 1440 queries attribute "way" of ticket 1306 (Figures 13 and 18A), thereby producing property "way" 
of ticket 1306. Property "way" of ticket 1306 is way 1820 (Figure 18A). Property "way" of ticket 1306 is optional 
and can therefore alternatively be a nil (not shown). 

If property "way" of ticket 1306 is a nil, processing transfers from test step 1440 to a ticket has provider 

25 test step 1460 which is described below in greater detail. Conversely, if property "way" of ticket 1306 is a way, 
i.e.. is not a nil, processing transfers from test step 1440 to step 1442 in which engine 132A(Figure 15A) queries 
attribute "name" of way 1820 (Figure 18A), thereby producing the telename that is property "name" of way 
1820. Also in step 1442 (Figure 14C), engine 132A (Figure 15A) produces and copies property "authority" of 
that telename. The resulting "authority", which is represented by an octet string as described in Appendix A, 

30 is used to determine the transfer destination, as described below. 

Processing transfers from step 1442 to a way has means test step 1444 (Figure 14C) in which attribute 
"means" of way 1820 (Figure 18B) is queried, thereby producing property "means" of way 1820, which is means 
object 1822. Property "means" is optional and can therefore alternatively be a nil (not shown). 

A means object, i.e., a member of class "Means", is an object which specifies an engine by specifying (i) 

35 an intercomputer communications medium and (ii) transfer instructions to reach a specific engine via that me- 
dium. For example, a means object can specify the public switched telephone network (PSTN) and specify 
modem instructions which include the telephone number of a specific modem through which to transfer the 
agent to a destination engine. As a means object contains all information needed to route agent 150A to a des- 
tination engine, other properties of ticket 1306 are ignored if ticket 1306 contains a means object. 

40 Therefore, if property "means" of way 1820 is not nil, i.e., is means object 1822 (Figure 18B), processing 

transfers from way has means test step 1444 (Figure 14C) to step 1446. In step 1446, way 1820 is designated 
as the way which defines the transfer destination. It should be noted that means object 1 822 defines the engine 
that is the destination of the first hop, i.e., the first transfer of agent 1 50A (Figure 1 5A), and not the destination 
of the trip defined by ticket 1 306 (Figure 1 8A), which is necessarily a place rather than an engine. Processing 

45 transfers from step 1446 to terminal step 1448 in which the processing of logic flow diagram 1414, i.e., route 
agent step 1414 (Figure 14B), completes successfully. 

Conversely, if property "means" of way 1820 (Figure 18B) is nil. way 1820 contains no means object and 
processing transfers from way has means test step 1444 (Figure 14C) to a ticket has name test step 1450. In 
ticket has name test step 1 450, engine 1 32A (Figure 1 5A) produces property "destinationlslame" of ticket 1 306 

50 (Figure 18A), which is telename 1818, and compares telename 1818 to a nil. As property "destinationName" 
of ticket 1306 is optional, property "destinationName" of ticket 1306 can be a nil (not shown). 

If property "destinationName" of ticket 1306 is a nil, processing transfers from ticket has name test step 
1 450 to ticket has provider test step 1 460, which is described below. Conversely, if property "destinationName" 
of ticket 1306 is telename 1818, processing transfers from ticket has name test step 1450 to step 1452. In step 

55 1 452, engine 132A (Figure 15A) produces a way object which defines a transfer path for agent 150A to the 
transfer destination. Engine 132A consults a finder, which is described in greater detail below, to produce a 
way object to a region associated with the authority produced and copied in step 1442 (Figure 14C) above, 
and a place within that authority whose name is equal to telename 181 8 (Figure 18A) . The production of such 
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a way object by use of a finder is described in greater detail below. 

Processing transfers from step 1452 to a way out is here test step 1454 in which engine 132A (Figure 15A) 
determines whether the way object produced in step 1452 (Figure 14C) defines a transfer to engine 132A(Fig- 
ure 15A). If the produced way object does not define a transfer to engine 132A, processing transfers from way 

5 out is here test step 1454 to terminal step 1456 in which the processing of logic flow diagram 1414, i.e., route 
agent step 1414 (Figure 14B). completes successfully. 

Conversely, if the produced way object defines a transfer to engine 132A (Figure 15A), processing trans- 
fers from way out is here test step 1454 to step 1458 in which engine 132Asets a flag indicating that agent 
150A is to be transferred to engine 132A. Processing transfers from step 1458 to a second ticket has name 

10 test step 1480 which is described below in greater detail. 

As discussed above, if property "way" of ticket 1306 is nil, processing transfers from ticket has way test 
step 1440 to ticket has provider test step 1460. In ticket has provider test step 1460, engine 132A produces 
property "destinationAddress" of ticket 1306, which is a teleaddress 1814 (Figure 18A), and produces property 
"provider" of teleaddress 1814. If either property "destinationAddress" of ticket 1306, or property "provider" of 

15 teleaddress 1814, is a nil, processing transfers from ticket has provider test step 1460 to second ticket has 
name test step 1480, which is described below in greater detail. Conversely, if property "destinationAddress" 
of ticket 1306 (Figure 18A) and property "provider" of the teleaddress 1814 are not nil, ticket 1306 specifies 
a region which contains the trip destination and processing transfers from ticket has provider test step 1460 
to step 1462. 

20 In step 1462, engine 132A (Figure 15A) consults a finder, as described below in greater detail, to produce 

a way object which defines a transfer to an engine of a region denoted by property "provider" of property "des- 
tinationAddress" of ticket 1 306. Processing transfers from step 1 462 (Figure 1 4C) to a first found test step 1 464 
in which engine 132A (Figure 15A) determines whether a way object is successfully produced in step 1462. If 
a way object is produced in step 1462, processing transfers from first found test step 1464 to a second way 

25 out is here test step 1472, which is described in greater detail below. Conversely, if no way object is produced 
in step 1462, processing transfers from first found test step to step 1466. 

In step 1466, engine 1 32A (Figure 15A) consults a finder, as described below in greater detail, to produce 
a way object which defines a transfer to a region denoted by an item of property "routingAdvice" of the tele- 
address that is property "destinationAddress" of ticket 1306. The properties of a teleaddress, and properties 

30 "provider" and "routingAdvice" in particular, are described in greater detail in Appendix A, and that discussion 
is incorporated herein by reference. Briefly, the items of property "routingAdvice" of a teleaddress denote pro- 
viders of zero or more regions which are believed by the creator of the teleaddress to be capable of transferring 
agent 150Ato the trip destination defined by ticket 1306 (Figure 18A). Processing transfers from step 1466 
(Figure 14C) to a second found test step 1468 in which engine 132A (Figure 15A) determines whether a.way 

35 object is successfully produced in step 1466. If no way object is produced in step 1466, processing transfers 
from second found test step 1 468 to terminal step 1 470 in which an exception of class "Destination Unavailable" 
is thrown. Conversely, if a way object is produced in step 1466, processing transr from second found test 
step 1468 to second way out is here test step 1472. 

In second way out is here test step 1472. engine 132A (Figure 15A) determines whether the way object 

40 produced in either step 1462 or step 1466 (Figure 14C) defines a transfer to engine 132A (Figure 15A). If the 
produced way object does not define a transfer to engine 132A. processing transfers from second way out is 
here test step 1472 to terminal step 1474 in which the processing of logic flow diagram 1414, i.e., route agent 
step 1414 (Figure 14B), completes successfully. 

Conversely, if the produced way object defines a transfer to engine 132A (Figure 15A), processing trans- 

« fers from second way out is here test step 1472 to step 1476 in which engine 132A (Figure 15A) derives a tel- 
ename, which identifies the destination of the trip defined by ticket 1306, from property "location" of the tel- 
eaddress that is property "destinationAddress" of ticket 1306. 

Engine 1 32A can derive the telename in any way which is convenient and efficient. For example, engine 
132A can use a table such as dictionary 2000 (Figure 20A) whose keys are octet strings, e.g., octet string 

so 2000K1 , and whose values are telenames. e.g., telename 2000V1 . For example, if property "location" of tel- 
eaddress 1814 (Figure 18A) equals octet string 2000K1 (Figure 20A), telename 2000V1 is produced by engine 
132A as the telename that specifies a place that is the destination of the trip defined by ticket 1306 (Figure 
18A). 

Addresses are assigned to locations within a region according to an addressing scheme designed and im- 
55 plemented by the designer and implementer of the engines of the region. The disclosed instruction set does 
not prescribe a particular addressing scheme. Each region is free to implement the most efficient and conve- 
nient addressing scheme for that particular region. Thus, as each sovereign state in the physical world designs 
and implements its own addressing scheme in providing a postal service, each region is free to implement a 
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unique addressing scheme for that region. Of course, the addressing schemes used within two or more regions 
need not be unique. 

In implementing an addressing scheme, engines of a region assign teleaddresses to locations which in- 
clude one or more places. In assigning a teleaddress, an engine produces and stores a telename which spe- 

5 cif ies one or more of the places within the location specified by the teleaddress. In other words, an engine, 
which assigns teleaddresses, maintains information which links teleaddresses to telenames of places to which 
respective teleaddresses are assigned. In this way, an engine, e.g., engine 132A (Figure 15A), can produce a 
telename of a place having a specified teleaddress. The particular mechanism by which such a telename is 
stored and produced is left up to the person or organization which designs and implements the engines of a 

10 given region. 

Processing transfers from step 1476 to step 1478 in which engine 1 32A (Figure 15A) sets a flag indicating 
that agent 150A is to be transferred to an engine within the region which contains engine 132A. Processing 
transfers from step 1478 (Figure 14C) to second ticket has name test step 1480 (Figure 14D). Processing also 
transfers to second ticket has name test step 1480 from step 1458 (Figure 14C) and from ticket has provider 

15 test step 1460, both of which are described above in greater detail. 

In second ticket has name test step 1 480 (Figure 1 4D), engine 1 32A (Figure 1 5A) determines whether prop- 
erty "destinationName" of ticket 1306 (Figure 18A), is a nil or telename 1818. If property "destinationName" 
of ticket 1306 is telename 1818, processing transfers from second ticket has name test step 1480 (Figure 14D) 
to step 1482 in which engine 132A (Figure 15A) produces a copy of telename 1818 (Figure 18A) and the copy 

20 supersedes the telename derived in step 1476 (Figure 14C) as the telename of the transfer destination. Proc- 
essing transfers from step 1482 (Figure 14D)tostep 1483. Additionally, if property "destinationName" of ticket 
1306 is a nil, processing transfers from second ticket has name test step 1480 directly to step 1483. 

In step 1483, engine 132A (Figure 15A) consults a finder, as described below in greater detail, to produce 
a way object which defines a transfer to a place denoted by the telename produced in either step 1476 (Figure 

25 14C) or step 1482 (Figure 14D) as described above. Processing transfers from step 1483 to test step 1484 in 
which engine 132A (Figure 15A) determines whether step 1458 (Figure 14C)sets the flag which indicates that 
the destination of the transfer is engine 1 32A (Figure 1 5A). If the flag is not set. processing transfers from test 
step 1484 to test step 1490 which is described below. Conversely, if the flag is set, the transfer of agent 150A 
(Figure 15A) should be to a place within engine 132A and processing transfers from test step 1484 (Figure 

30 14D) to a third way out is here test step 1486. 

In third way out is here test step 1486, engine 132A (Figure 15A) determines whether the way object pro- 
duced in step 1483 (Figure 14D) defines a transfer to engine 132A (Figure 15A). If the produced way object 
does not define a transfer to engine 1 32A, processing transfers from third way out is here test step 1486 (Figure 
14D) to terminal step 1488 in which an exception of class "Destination Unavailable" is thrown and processing 

35 according to logic flow diagram 1414 (Figures 14C and 14D). i.e., route agent step 1414 (Figure 14B), com- 
pletes. Conversely, if the produced way object defines a transfer to a place within engine 132A (Figure 15A), 
processing transfers from test step 1486 (Figure 14D) to test step 1490. 

In test step 1490, engine 132A (Figure 15A) determines whether step 1478 (Figure 14C) sets the flag which 
indicates that the destination of the transfer is the region which includes engine 132A (Figure 15A). If this flag 

40 is not set, processing transfers from test step 1 490 to terminal step 1 496 in which processing according to logic 
flow diagram 1414 (Figures 14C and 14D), i.e., route agent step 1414 (Figure 14B), completes successfully. 
Conversely, if the flag is set, the transfer of agent 150A (Figure 15A) should be to a place within the region 
which includes engine 132Aand processing transfers from test step 1490 (Figure 14D)to way out is this region 
test step 1492. In way out is this region test step 1492, engine 132A (Figure 15A) determines whether the way 

45 object produced in step 1483 (Figure 14D) defines a transfer to a place within the region which includes engine 
132A (Figure 15A). If the produced way object does not define a transfer to a place within the region which 
includes engine 1 32A, processing transfers from way out is this region test step 1492 (Figure 14D) to terminal 
step 1494 in which an exception of class "Destination Unavailable" is thrown and processing according to logic 
flow diagram 1414 (Figures 14C and 14D), i.e., route agent step 1414 (Figure 14B), completes. 

so As discussed above with respect to steps 1452, 1462, 1466 and 1483 (Figure 14C), engine 1 32A (Figure 

132A) uses a finder to route agent 150A in a transfer toward a destination of the trip defined by ticket 1306 
(Figure 1 3A). A finder is used to determine the transfer destination for an agent. For example, ticket 1 306 (Fig- 
ure 13A) defines place 220B (Figure 15A) within engine 132B as a destination of the trip. However, to reach 
engine 132B, agent 150A must first be transferred to engine 132Z. which is therefore the transfer destination. 

55 Finder 2050 (Figure 20B) is used to produce a telename of an engine that is a transfer destination toward a 
place, which is identified by a second telename. In one embodiment, the produced telename identifies an en- 
gine by identifying the engine place processed by the engine. The second telename can identify a specific 
place or an authority,, thereby specifying all places of the identified authority. Telenames are described in 
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greater detail in Appendix A. 

In the context of step 1452 (Figure 14C), the second telename is telename 1818 (Figure 18A), which is 
property "destinationName" of ticket 1 306. If finder 2050 (Figure 20B) contains no information regarding tele- 
name 1818, the second telename, in the context of step 1452 (Figure 14C), is a telename which identifies the 

5 authority produced and copied in step 1442 as described above. In the context of step 1462, the second tele- 
name identifies the authority specified in property "provider" of teleaddress 1814 (Figure 18A) of ticket 1306. 
In the context of step 1466 (Figure 14C), the second telename identifies the authority specified in an item of 
the list that is property "routingAdvice" of telename 1814 (Figure 18A) of ticket 1306. In the context of step 
1483 (Figure 14D), the second telename is either telename 1818 (Figure 18A) of ticket 1306. if property "des- 

w tinationName" of ticket 1306 is not nil. or the telename produced in step 1476 (Figure 14C), otherwise. Finder 
2050 (Figure 20B) is described below in the context of step 1483 (Figure 14D) in which the second telename 
is telename 1818 (Figure 18A) of ticket 1306. 

In each of steps 1452 (Figure 14C), 1462, 1466, and 1483 (Figure 14D), the telename produced by use of 
finder 2050 (Figure 20B) is used to form a way object which defines a transfer to the engine identified by the 

15 produced telename. 

Engine 1 32A determines to which engine to transfer agent 1 50A, i.e., the "transfer destination", by use of 
a finder 2050 (Figure 20B). Finder 2050 can be any data structure which allows engine 132Ato determine, 
from a trip destination, a transfer destination that moves agent 150A toward the trip destination. In one em- 
bodiment, finder 2050 is a dictionary whose keys are telenames and whose values are also telenames. The 

20 keys, e.g., telenames 2050K1-2050K6, specify authorities. The values, e.g., telenames 2050V1-2050V6, iden- 
tify engines through which places identified by each respective corresponding authority can be reached. If 
telename 2050K1 (Figure 20B) of finder 2050 has the same authority as that of telename 1818, telename 
2050V1 identifies engine 132Z as the transfer destination. 

In one embodiment of the present invention, the keys of finder 2050 include a nil 2050K7, which is asso- 

25 ciated with a telename 2050V7. Telename 2050V7 identifies an engine which contains information regarding 
a substantial portion of network 1500 (Figure 15A) and networks to which network 1500 can be connected, 
either directly or indirectly. The engine which is identified by telename 2050V7 is therefore more likely to have 
success in routing agent 1 50A toward a trip destination which satisfies ticket 1 306 (Figure 1 8A) . If no telename 
which is a key of finder 2050 (Figure 20B) is of the same authority as telename 1818, telename 2050V7 (Figure 

30 20B). which is associated with nil 2050K7, identifies the transfer destination. The following example is illus- 
trative. 

Suppose, for example, that engine 1 32A is executing within a small personal computer system and there- 
fore interprets places of only one authority. Suppose further that engine 132Z (Figure 15A) is executing within 
a large, multi-user, mainframe computer system which interprets places of many separate authorities and to 

35 which many agents of many different authorities travel. The finder of engine 132A would, in such a case, be 
very small and provide little information regarding the transportation of agents to places of particular author- 
ities. However, the finder of engine 132Z is likely to be much more extensive and comprehensive, and therefore 
much more likely to provide information regarding the routing of a particular agent to places of particular au- 
thorities. In such a case, the finder of engine 132A associates with a nil a telename which identifies engine 

40 1 32Z as the transfer destination when the finder of engine 1 32A contains no information regarding the authority 
of the trip destination place. 

If no transfer destination is successfully determined from consulting finder 2050 (Figure 20B), an engine 
can implement any of the following or other policies according to the implementation chosen by the provider 
of the engine. If ticket 1306 (Figure 18A) contains citation 1816, engine 132A (Figure 15A) can (i) produce a 

45 telename to the current place of agent 1 50A and attempt to find a place of the cited class in the steps described 
below, (ii) throw an exception and produce no telename, thereby rejecting ticket 1306 (Figure 18A) as vague, 
or (iii) produce a telename of a place which is designated as a destination of vaguely specified trips. Similarly, 
if ticket 1306 includes no citation, engine 132A (Figure 15A) can (i) throw an exception and produce no tele- 
name, thereby rejecting ticket 1306 (Figure 18A) as vague, or (ii) produce a telename of a place which is des- 

50 ignated as a destination of vaguely specified trips. 

In the example of Figures 15A-15E, engine 132A (Figure 15A) consults finder 2050 (Figure 20A) and de- 
termines that, to reach place 220B (Figure 15A) of engine 132B, agent 150Aisto be transferred to engine 132Z. 
Therefore, the engine place of engine 132Z is the transfer destination of agent 150A and a way object, which 
defines a transfer of agent 150A to engine 132Z, is produced. 

55 Thus, processing according to logicflow diagram 1414 (Figures 14C and 14D) produces a way object which 

defines a transfer of agent 150A (Figure 15A) to move agent 150A toward the destination of the trip defined 
by ticket 1306. 

As discussed above in the context of logic flow diagram 1410 (Figure 14B), agent 150A (Figure 15A) is 
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delivered to a place in deliver agent step 1422 (Figure 14B). It is reiterated that, in the illustrative example of 
Figures 15A-15E, agent 150A is not delivered to any place within engine 132A. However, for completeness, 
the delivery of agent 150A to a place within engine 132A is discussed. Agent 150A (Figure 15A) is delivered 
to a place within engine 132A when that place is defined by ticket 1306 (Figure 13A) as the trip destination. 

5 Delivering an agent to a place involves (i) selecting a particular place to deliver the agent, (ii) making the agent 
an occupant of that place, and (iii) causing operation "go" to succeed for that agent. Deliver agent step 1422 
is represented by logic flow diagram 1422 (Figure 14E). 

Processing according to logic flow diagram 1422 (Figure 14E) begins with for all current places step 1422A. 
For all current places step 1422A and next step 1422C define a processing loop in which each of the places 

10 currently processed by the current engine, i.e., engine 132A (Figure 15A), is processed according to steps 
1422B, 1422D, and 1422E (Figure 14E). In the context of the following discussion of logic flow diagram 1422, 
the "subject place" is the place which is processed in a particular iteration of the loop defined by for all current 
places step 1422A and next step 1422C. For each iteration of the loop, i.e.. for each current place of engine 
132A (Figure 15A), processing transfers from for all current places step 1422A to a place satisfies ticket test 

15 step 1422B. 

In place satisfies ticket test step 1422B, the current engine determines whether the subject place satisfies 
ticket 1306. 

If the subject place does not satisfy ticket 1306, either (i) processing transfers from place satisfies ticket 
test step 1422B (Figure 14E) through next step 1422C to for all current places step 1422A in which another 
20 iteration of the loop is begun, or (ii) processing transfers to terminal step 1 422I. which is described below. Con- 
versely, if the subject place satisfies ticket 1306. processing transfers from place satisfies ticket test step 
1422B to entering step 1422D. 

As described below in greater detail, a place grants ingress % process, e.g. an agent, by successfully 
performing operation "entering" and denies ingress to a process by [hrowing an exception during performance 
25 of operation "entering". Performance of operation "entering" is discussed in greater detail below. 

Processing transfers from entering step 1422D (Figure 14E) to exception test step 1422E in which the cur- 
rent engine determines whether performance of operation "entering" by the subject place threw and exception. 
If performance of operation "entering" by the subject place threw an exception, thereby denying agent 150A 
ingress to the subject place, processing transfers from entering step 1422E through next step 1422C to for all 
30 current places step 1422A in which another iteration of the loop defined by for all current place step 1422A 
and next step 1422C is begun or processing transfers to terminal step 1422J, which is described below. 

If. on the other hand, operation "entering" is performed successfully by the subject place, the subject place 
thereby granting to agent 150A (Figure 15A) ingress to the subject place, processing transfers from exception 
test step 1422E (Figure 14E) to step 1422F. In step 1422F, agent 150A (Figure 150A) is made an occupant of 
35 the subject place. Furthermore, a property of agent 150A is set to indicate that agent 150A is an occupant of 
the subject place. 

Processing transfers from step 1422F to step 1422G in which operation "go" as performed by agent 150A 
succeeds. As discussed above, agent 1 50A is not delivered to a place in engine 1 32A in the example of Figures 
15A-15E. Therefore, operation "go" for agent 150Adoes not succeed until agent 150A(Figure 15A) is delivered 

40 to place 220B in engine 132B (Figure 15E) as discussed below. Processing transfers from step 1422G (Figure 
14E) to terminal step 1422H in which processing according to logic flow diagram 1422, and therefore deliver 
agent step 1422 (Figure 14B), completes successfully. 

If all places which are current in engine 132A (Figure 15) are processed according to the loop defined by 
for all current places step 1422A (Figure 14E) and next step 1422C and terminal step 1422H is not reached, 

45 i.e., if no place that is current in engine 1 32A (Figure 1 5A) satisfies ticket 1 306 and grants agent 1 50A occu- 
pancy via successful performance of operation "entering", processing transfers from for all current place step 
1422A (Figure 14E) to terminal step 14221. In terminal step 14221, an exception of class "Destination Unavail- 
able" is thrown and logic flow diagram 1422. and therefore deliver agent step 1422 (Figure 14B), completes. 
Thus, deliver agent step 1422 delivers agent 150A (Figure 15A) to a place identified by ticket 1306 (Figure 

so 13A) as the destination of a trip or throws an exception of class "Destination Unavailable". 

As discussed above, in the example of Figures 15A-15E, engine 132Z is the transfer destination. Agent 
150Ais therefore en coded to form encoded agent 150A-E (Figure 15B) in step 1432 (Figure 14B) which is then 
transferred to engine 132Z (Figure 15C) in transfer out step 1434 (Figure 14B). 

55 Operation "Go" from the Perspective of an Intermediate Engine 

As described above, transfer of encoded agent 150A-E (Figure 15B) from communication infrastructure 
132A-CI, across communications link 102AZ, to communication infrastructure 132Z-CI (Figure 15C) is initiated 
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in transfer out step 1434 (Figure 14B). Appended to encoded agent 150A-E (Figure 21) is destination 150A- 
E-D, which includes properties "name", "address" and "data" which are telename 2102, teleaddress 2104 and 
octet string 2106, respectively. Telename 2102 and teleaddress 2104 define the transfer destination of encod- 
ed agent 150A-E. The transfer destination as defined by destination 150A-E-D (Figure 21) can be either engine 

5 132Z (Figure 15B) or engine 132B. In one embodiment of the present invention, destination 150A-E-D (Figure 
21), which is formed in form destination step 1430 (Figure 14B). defines engine 132Z (Figure 15B) as the trans- 
fer destination of encoded agent 150A-E. In that case, communications infrastructure 132A-CI transfers en- 
coded agent 150A-E directly to communications infrastructure 132Z-CI of engine 132Z. In another embodi- 
ment of the present invention, destination 150A-E-D (Figure 21) defines engine 132B (Figure 15B) as thetrans- 

10 fer destination of encoded agent 150A-E. In the latter case, communications infrastructure 132A-CI contains 
information and logic which causes communications infrastructure 132A-CI to transfer encoded agent 150A- 
E. which is destined for engine 132B according to destination 150A-E-D (Figure 21), to communications infra- 
structure 132Z-CI (Figure 15B) or engine 132Z. 

In either embodiment described above, when engine 132Z (Figure 15C) receives encoded agent 150A-E. 

15 engine 132Z performs a system operation determined in route agent step 1414 "transferln" which is shown as 
logic flow diagram 1400-1 (Figure 14F). Engine 132Z (Figure 15C) begins performance of system operation 
"transferln" by producing a way object which defines a transfer to destination 150A-E-D (Figure 21) in step 
1402-1 (Figure 14F). Engine 132Z produces a way object in step 1402-1 (Figure 14F) by consulting a finder 
within engine 132Z (Figure 15C) as described above with respect to finder 2050 (Figure 20B). 

20 Processing transfers from step 1402-1 (Figure 14F) to a fourth way out is here test step 1404-1 in which 

engine 132Z (Figure 15C) determines whether the way object produced in step 1402-1 (Figure 14F) defines a 
transfer to engine 132Z (Figure 15C). If the produced way object does not specify engine 132Z (Figure 15C) 
as the transfer destination, i.e., if destination 150A-E-D (Figure 21) defines engine 132B (Figure 15B) as the 
transfer destination, processing transfers from fourth way out is here test step 1404-1 (Figure 14Fs) to a second 

25 transfer out step 1406-1. In second transfer out step 1406-1, engine 1 32Z (Figure 1 5C) initiates transfer of en- 
coded agent 150A-E according to destination 150A-E-D (Figure 21) in a manner directly analogous to that de- 
scribed above with respect to transfer out step 1434 (Figure 14B). 

Processing transfers from second transfer out step 1406-1 to step 1408-1. In step 1408-1, engine 132Z (Fig- 
ure 15C) adds encoded agent 150A-E to a list of pending transfers as described above with respect to step 

30 1 438 (Figure 14B). Processing transfers from step 1408-1 (Figure 14F) to terminal step 1410-1 in which system 
operation "transferln" completes successfully. 

Thus, if the way object produced in step 1402-1 defines a transfer to engine 132B (Figure 15C), encoded 
agent 150A-E is transferred according to the produced way object. If, on the other hand, the produced way 
object defines a transfer to engine 1 32Z, processing transfers from fourth way out is here test step 1 404-I (Fig- 

35 ure 14F) to step 1412-1. In step 1412-1. engine 132Z (Figure 15C) extracts from encoded agent 150A-E ticket 
1306 (Figures 13A and 18A) and forms a copy of ticket 1306. Processing transfers from step 1412-1 to step 
1414-1 in which property "way" of the ticket copy is cleared, i.e.. set to a nil. Processing transfers from step 
1414-1 to a second route agent step 1416-1 in which engine 132Z produces a way object defining a transfer of 
encoded agent 150A-E. The process performed in step 1416-1 is identical to the process represented by logic 

40 flow diagram 1414 (Figures 14C and 14D). In the context of second route agent step 1416-1, ticket 1306 used 
in the above discussion of logic flow diagram 1414 is replaced by the ticket copy made in step 141 2-I, and the 
logic flow diagram is processed as described above using the ticket copy. Upon completion of step 1416-1, 
processing transfers to a fifth way out is here test step 1418-1. 

In fifth way out is here test step 1418-1, engine 132Z (Figure 15C) determines whether the way object pro- 

45 duced in step 1416-1 (Figure 14F) defines a transfer to engine 132Z (Figure 15C). If the produced way object 
defines a transfer to engine 132Z. processing transfers from fifth way out is here test step 1418-1 (Figure 14F) 
to a decode agent step 1428-1 which is described below in greater detail. Conversely, if the produced way object 
does not define a transfer to engine 132Z (Figure 15C), processing transfers from fifth way out is here test 
step 1418-1 (Figure 14F) to a second form destination step 1420-1. In the example of Figures 15A-15F, ticket 

50 1306 (Figure 13A), which is extracted from encoded agent 150A-E and copied, defines a trip to place 220B 
of engine 132B (Figure 15C). Therefore, processing transfers to second form destination step 1420-1. 

In form destination step 1420-1, engine 132Z (Figure 15C) forms, i.e., supersedes, destination 150A-E-D 
(Figure 21 ) in a manner that is directly analogous to that described above with respect to form destination step 
1430 (Figure 14B). Processing transfers from second form destination step 1420-1 (Figure 14F) to a third trans- 

55 fer out step 1422-1. In third transfer out step 1422-1, encoded agent 150A-E (Figure 15C) is transferred accord- 
ing to destination 150A-E-D (Figure 21) as described above with respect to second transfer out step 1406-1 
(Figure 14F). 

Processing transfers from third transfer out step 1422-1 to step 1424-1. In step 1424-1, engine 132Z (Figure 
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15C) adds encoded agent 150A-E to a list of pending transfers as described above with respect to step 1438 
(Figure 14B). Processing transfers from step 1424-1 (Figure 14F) to terminal step 1426-1 in which system op- 
eration "transferln" completes successfully. In the example of Figures 15A-15F, encoded agent 150A-E is 
transferred from engine 1 32Z to engine 1 32B (Figure 1 5D) in a manner that is directly analogous to the transfer 
5 of encoded agent 150A-E from engine 1 32A to engine 132Z as described above. 

Operation "Go" from the Perspective of the Destination Engine 

When engine 132B receives encoded agent 150A-E in communication infrastructure 132A-CI (Figure 

10 15D), engine 132B performs system operation "transferln" in a manner similar to that described above with 
respect to engine 1 32Z. Engine 1 32B produces a way object defining a transfer according to destination 1 50A- 
E-D (Figure 21 ) in step 1402-1 (Figure 14F) and determines whether the produced way object defines a transfer 
to engine 132B (Figure 15D) in fourth way out is here test step 1404-1 (Figure 14F). Since engine 132B (Figure 
15D) processes place 220B which is the destination of the trip defined by ticket 1306 (Figure 13A), the pro- 

75 duced way object defines a transfer to engine 1 32B (Figure 1 5D). Therefore, processing by engine 1 32B trans- 
fers from fourth way out is here test step 1404-1 (Figure 14F) to step 1412-1. 

In steps 1412-1, 1414-1 and 1416-1, engine 132B extracts and copies ticket 1306 (Figure 13A) from encoded 
agent 150A-E, clears property "way" of the ticket copy, and routes encoded agent 150A-E according to logic 
flow diagram 1414 (Figures 14C and 14D) except now the ticket copy is used for ticket 1306 in the above de- 

20 scription. In fifth way out is here test step 1418-1 (Figure 14F), engine 132B (Figure 15D) determines whether 
the way object produced in second route agent step 1416-1 (Figure 14F) defines a transfer to engine 1 32B (Fig- 
ure 15D). Since engine 132B (Figure 15D) processes place 220B, the produced way object defines a transfer 
to engine 132B (Figure 15D). Therefore, processing by engine 132B transfers from fifth way out is here test 
step 1418-1 (Figure 14F) to decode agent step 1428-1. 

25 In decode agent step 1428-1, engine 132B decodes agent 150Afrom encoded agent 150A-E (Figure 15D) 

in communication infrastructure 132B-CI by reverse application of the encoding rules described in Appendix 
B and stores agent 150A in data portion 132B-D (Figure 15E). As network 1500 can be heterogeneous, the 
form of agent 150A within engine 132A (Figure 15A) may be inconvenient for representing agent 150A within 
engine 1 32B (Figure 1 5E). As long as the standardized form of encoded agent 1 50A-E is used to transfer agent 

30 1 50A between engines 1 32A and 1 32B. engine 1 32B can represent agent 1 50A in whatever form is most con- 
venient for engine 132B when not transferring agent 150A. 

Processing by engine 132B transfers from decode agent step 1428-1 (Figure 14F) to deliver agent step 
1430-1. In deliver agent step 1430-1. agent 150Ais delivered according to logic flow diagram 1422 (Figure 14E) 
as described above with respect to deliver agent step 1422 (Figure 14B). In the context of deliver agent step 

35 1 430-I, the ticket is now the actual ticket 1 306 (Figure 1 3A) and not the postulated ticket. In deliver agent step 
1430-1 (Figure 14F), agent 150A (Figure 15E) is granted occupancy in place 220B and operation "go" as per- 
formed by agent 150A completes successfully. 

Processing transfers from deliver agent step 1430-1 (Figure 14F) to terminal step 1426-1 in which process- 
ing according to logic flow diagram 1400-1 (Figure 14F), i.e., performance of system operation "transferln", by 

40 engine 132B completes successfully. 

Any exception thrown in the course of performing the steps of logic flow diagram 1400-1 (Figure 14F) caus- 
es performance of the steps of logic flow diagram 1450-1 (Figure 14G). Agent 150A is decoded from encoded 
agent 150A-E (Figure 15D) in step 1452-1 (Figure 14F). Since agent 150A arrived in engine 132B (Figure 15D), 
agent 1 50A is not retained in a list of pending transfers as described above with respect to engine 1 32A. There- 

45 fore, it is necessary to decode agent 150A to continue execution of agent 150A. Processing transfers from 
step 1 452-I (Figure 1 4G) to deliver agent step 1454-1 in which agent 1 50A is delivered to purgatory as described 
above with respect to step 1426(Figure 14B). Processing transfers from deliver agent step 1454-1 (Figure 14G) 
to terminal step 1456-1 in which processing according to logic flow diagram 1450-1 completes. Agent 150A. 
which occupies purgatory as a result of deliver agent step 1454-1, throws the exception which caused perfor- 

50 mance of logic flow diagram 1 450-I, thereby causing operation "go" as performed by agent 1 50A to fail. 

Thus, agent 150A (Figures 15A-15E), by performance of operation "go", directs movement, i.e., transpor- 
tation, of agent 150A, and objects owned by agent 150A such as objects 140A and 140B, through network 
1500. After performance of operation "go", interpretation of agent 150A continues with the instruction within 
agent 150A which immediately follows operation "go". 

55 Figure 1 3B shows a portion of the execution state and of the internal state of agent 1 50A immediately fol- 

lowing performance of operation "go" by agent 150A. At the top of stack 1304 is ticket stub 1308 which is the 
result produced by performance of operation "go". Place 220B is the property of agent 150A identifying the 
place occupied by agent 150A. thereby indicating that agent 150A occupies place 220B. 
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Ingress and Egress: Operations "Entering" and "Exiting" 

As discussed above, place 220B grants or denies ingress to agent 1 50A by performance of operation "en- 
tering". The embodiment disclosed above with respect to logic flow diagram 1400 (Figures 14Aand 14B) trans- 

5 ports encoded agent 150A-E (Figures 15A-15E) to engine 132B before requesting that place 220B perform 
operation "entering". In another embodiment of the present invention, place 220B is directed to perform oper- 
ation "entering" before agent 150A is transported across communications link 102AZ, through communication 
infrastructure 132Z-CI, across communications link 102ZB to engine 132B. By performing operation "enter- 
ing", place 220B either grants or denies agent 150A permission to occupy place 220B. However, it is anticipated 

w that the present invention will be used in wide-area networks with high latency. 

The term "latency" is used herein as it is used in the art to denote the amount of time between the time 
information is first sent by the sender of the information and the time information is first received by the receiver 
of the information. In networks with high latency, even short messages can require substantial amounts of time 
to reach a destination. In such a case, requesting that place 220B (Figure 15A) perform operation "entering" 

15 and awaiting a result involves sending a request across communications link 102AZ, through communication 
infrastructure 132Z-CI, across communications link 102ZB and through engine 132B to place 220B to perform 
operation "entering" and awaiting receipt of the result produced by operation "entering" by the reverse path. 
Doing so before transporting agent 150A to engine 132B postpones the transportation of agent 150A to engine 
1 32B by an amount of time approximately equal to twice the latency between engines 1 32A and 1 32B. There- 

20 fore, to substantially improve the performance of the present invention, performance of operation "entering" 
by place 220B is postponed until agent 150A is transported to engine 132B. 

While operation "entering" is described in the context of agent 1 50A (Figure 1 5E) entering place 220B as 
a consequence of operation "go", operation "entering" is also performed as a consequence of a process, either 
an agent or a place, entering place 220B as a consequence of the process's creation within place 220B. The 

25 creation of a process is discussed in greater detail in Appendix A. 

Figure 22A gives the execution state of agent 1 50A immediately prior to performance of operation "enter- 
ing". The execution state of a process, e.g.. agent 150A, is described in greater detail below. Operation "en- 
tering" is performed at the request of engine 132B. and the performance of "entering" is recorded in the exe- 
cution state of agent 1 50A (Figure 1 5E). The permit of either agent 1 50A or place 220B, preferably place 220B, 

30 may be debited by performance of operation "entering". 

Frame 2200 is part of the execution state of agent 150A and records the dynamic state of operation "en- 
tering" as performed by place 220B. Frame 2200 includes stack 2202 which is the current stack. Stack 2202 
contains, from top to bottom, contact 2208. permit 2206 and ticket 2204. 

Contact 2208 identifies agent 150Aas the process attempting to enter place 220B. As discussed below 

35 in greater detail and in Appendix A, a contact has, among its properties, a property "subjectName" and a prop- 
erty "subject". Property "subject" of contact 2208. which is ordinarily a reference to agent 150A, is nil in oper- 
ation "entering" so that place 220B is not given a reference to agent 150A before place 220B grants ingress 
to agent 1 50A. Property "subjectName" of contact 2208 is a telename which identifies agent 1 50A as the agent 
requesting ingress to place 220B. 

40 Permit 2206 is the proposed local permit of the agent attempting to "enter" place 220B. Permit 2206 is 

passed "byProtectedRef" and therefore cannot be altered by performance of operation "entering". The passing 
of arguments and results, and in particular passing by protected reference, i.e., "byProtectedRef", is described 
below in greater detail. An agent's local permit defines the capabilities of the agent while at a given place. For 
example, agent 150A can limit itself to a subset of the capabilities and allowances of its native permit while at 

45 place 220B by supplying to place 220B permit 2206 which defines the subset of capabilities and allowances. 

Ticket 2204 is passed "byProtectedRef" and is equal to ticket 1 306 used to travel to responding piace 220B 
and informs responding place 220B that agent 150A is attempting to enter from another place. If ticket 2204 
is a nil, a process is attempting to enter responding place 220B by the process's creation within responding 
place 220B. 

50 The method by which a place determines whether to admit a process, i.e., the method implementing op- 

eration "entering", as defined by class "Place" always throws an exception that is a member of class "Occu- 
pancy Denied", thereby denying the process ingress to the responding place. However, users of the present 
invention define subclasses of class "Place" which grant entrance to processes under specific circumstances. 
Such is a practical necessity for agents to travel from one place to another. 

55 As the implementation of operation "entering", as performed by a place, is defined by the particular method 

provided by or inherited by the class of which the place is an instance, each place can implement operation 
"entering" differently from other places in the network. Logic flow diagram 2260 (Figure 22C) serves as an 
illustrative example of an implementation of operation "entering" and therefore of the steps taken by place 220B 
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in performance of operation "entering" in entering step 1448 (Figure 14B). 

Contact 2208, permit 2206 and ticket 2204 are popped from stack 2202 in steps 2262, 2264 and 2266, 
respectively (Figure 22C). Processing then transfers to ticket test step 2272 in which ticket 2204 is compared 
to a nil. If ticket 2204 is a nil, agent 150A is being created locally and processing transfers to terminal step 
5 2274 where operation "entering" completes successfully. However, it is apparent in view of the foregoing and 
the following that a place can be defined such that operation "entering" fails under certain circumstances so 
as to prevent the creation of a process within the place. 

If ticket 2204 is not nil, processing transfers from ticket test step 2272 to allowance test step 2276. In al- 
lowance test step 2276. property "charges" of permit 2206 is produced by querying attribute "charges" of permit 
10 2206 and property "charges" of permit 2206 is compared to 1 000. If property "charges" of permit 2206 is greater 
than 1000, processing transfers from allowance test step 2276 to terminal step 2278 where an exception of 
class "Occupancy Denied" is thrown, denying the agent ingress into the responding place. If property "charges" 
of permit 2206 is less than or equal to 1000, processing transfers from allowance test step 2276 to terminal 
step 2274 where operation "entering" terminates successfully, granting the agent ingress into the responding 
15 place. The exact number 1000 as a maximum permissible charges allowance in the example of Figure 22C is 
chosen arbitrarily for purposes of illustration. 

The method of logic flow diagram 2260 is illustrative of an appropriate implementation of operation "en^ 
tering" for places processed by an engine operating within a personal computer system with limited resources. 
As discussed above and in Appendix A, property "charges" of a permit is an allowance of processing. Thus, 
20 according to logic flow diagram 2260, agents, which indicate by a large charges allowance in their proposed 
local permits a need for large amounts of computation and resources, are denied ingress. Thus, the owner of 
a small personal computer system can restrict her personal computer system to processes created locally and 
to relatively inexpensive visits by agents created elsewhere. 

Immediately following performance of operation "entering" by place 220B (Figure 22B), stack 2202 is emp- 
25 ty as operation "entering" produces no result. 

As discussed above, a place notes the departure, i.e., the termination of occupancy, of a process by per- 
formance of operation "exiting". In the context of logic flow diagram 1400 (Figures 14Aand 14B), place 220A 
is performing operation "exiting" as a result of an agent, i.e., agent 1 50A. leaving place 220A as a consequence 
of operation "go". Operation "exiting" is also performed by place 220A when a process, either an agent or a 
30 place, no longer occupies place 220A as a consequence of the process's destruction. The destruction of a 
process is described in greater detail in Appendix A. The interface of operation "exiting" as define class 
"Place" is shown by Figures 23A and 23B. 

As operation "exiting" is performed at the request of engine 132A (Figure 15A). frame 2300 (Figure 23A), 
which records the dynamic state of operation "exiting", is neither part of the execution state of place 220A (Fig- 
35 ure 15A) nor part of the execution state of agent 150A. In fact, at the time at which place 220A is performing 
operation "exiting", agent 150A no longer occupies place 220A. Engine 132A creates a new execution state 
as part of an "engine process". An engine process is a process created by an engine for the purpose of carrying 
out a performance of operation "exiting" or of operation "parting". Operation "parting" is discussed below and 
in Appendix A. 

40 Figure 23A illustrates frame 2300 immediately prior to performance of operation "exiting". Frame 2300 in- 

cludes stack 2302. which is the current stack. Stack 2302 contains as the arguments of operation "exiting", 
from top to bottom, contact 2308. permit 2306 and ticket 2304. 

Contact 2308 identifies agent 150A (Figure 15A) as the process exiting place 220A. As discussed below 
in greater detail and in Appendix A, a contact has, among its properties, a property "subjectName" and a prop- 

45 erty "subject". Property "subjectName" of contact 2308 (Figure 23A) identifies agent 150A (Figure 15A); prop- 
erty "subject" of contact 2308 (Figure 23A), which is ordinarily a reference to agent 150A (Figure 15A), is voided 
in operation "exiting" so that place 220A is not left with a reference to exiting agent 150A. 

Permit 2306 (Figure 23A) is the current local permit of the process exiting responding place 220A (Figure 
1 5A), i.e. of agent 1 50A, A process's local permit defines the capabilities of the process while occupying a given 

50 place. Local permits are discussed in greater detail in Appendix A. Permit 2306 (Figure 23A) is passed "by- 
ProtectedRef and therefore cannot be altered by place 220A (Figure 15A) in performing operation "exiting". 

The local permit of the exiting process, i.e., permit 2306 (Figure 23A), is used by the engine interpreting 
responding place 220A (Figure 1 5A) to determine the type and amount of resources used by the exiting process 
during occupancy of place 220A so that the authority of the exiting process can be billed for use made of place 

55 220Aand resources contained therein. The type and amount of resources used are determined by comparison 
between permit 2306 (Figure 23A) and the permit consumed as an argument in operation "entering" when 
granting ingress to the exiting process. Operation "entering" is discussed in greater detail above and in Ap- 
pendix A. 
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For example, place 220A (Figure 1 5A) in performing operation "entering", can store the proposed local per- 
mit, e.g., permit 2206 (Figure 22A), for later comparison with permit 2306 (Figure 23A), which is consumed in 
performance of operation "exiting". As described below and in Appendix A, a contact, e.g., contact 2308, has 
a property "subjectNotes". In one embodiment, place 220A stores, within property "subjectNotes" of contact 
5 2208 (Figure 22A), permit 2206 in performing operation "entering". In performing operation "exiting", place 
220A (Figure 15A) determines the amount of resources consumed by agent 150A while occupying place 220A 
by comparing permit 2206 (Figure 22A), which is stored within property "subjectNotes" of contact 2208, with 
permit 2308 (Figure 23A), which is consumed in performance of operation "exiting". 

Ticket 2304 (Figure 23A) is passed "byProtectedRef" and is equal to ticket 1 306 (Figure 1 3A) which is used 
w by agent 150A (Figure 15A) to specify the destination of the trip and informs responding place 220A that agent 
150Ais leaving responding place 220Aas a consequence of performing operation "go". If ticket 2304 (Figure 
23A) is a nil, agent 150A (Figure 15A) is exiting responding place 220Aas a consequence of the destruction 
of agent 150A. 

Frame 2300 (Figure 23B) is shown immediately following performance of operation "exiting" by place 220A 
15 (Figure 1 5A) . Stack 2302 (Figure 23A) is empty as operation "exiting" produces no result. As frame 2300 (Fig- 
ure 23B) is not part of the execution state of either place 220A (Figure 1 5A) or agent 1 50A, but is instead part 
of the execution state of an engine process, any exception thrown by performance of operation "exiting" is not 
experienced by, and therefore has no effect upon, either place 220Aor agent 150A. In performing operation 
"exiting", place 220A notes the departure of agent 150Aand objects 140Aand 140B, which are owned by agent 
20 1 50A. 

Object Interchange 

The time required to transport an agent from one place to another is substantially reduced by limiting trans- 

25 portation of objects contained by the agent to only those objects that are not likely to have an equivalent object 
at the destination place. Limiting transportation of such objects is particularly important as agent 1 50A, in trav- 
eling from engine 132A to engine 132Z. includes class objects representing the classes of which agent 150A 
and objects owned by agent 150A are members. As class objects are typically quite large and as the classes 
of which an agent and the objects owned by the agent are members are typically quite numerous, transporting 

30 all such class objects is impractical. Thus, it is preferred that, in transporting agent 150Afrom engine 132Ato 
engine 1 32B (Figure 1 5A), only class objects representing classes, which are not represented by class objects 
in engine 132B, are transported with agent 150A to engine 132B. 

Objects, that are likely to have equivalent objects at most places within network 1500 (Figures 15A-15E), 
are members of mix-in class "Interchanged" and therefore include a property "digest". Members of mix-in class 

35 "Interchanged" are called "interchanged objects". The object which is property "digest" of an interchanged ob- 
ject is alternatively called "the digest" of the interchanged object. 

An interchanged object is one that an engine, e.g. engine 132Aor 132B (Figure 15A), deems equivalent 
to any other instance of the interchanged object's class whose digest is equal to the digest of the interchanged 
object. A digest is any object suited to the purpose of distinguishing a first interchanged object from all others. 

40 For example, a mathematical hash of a canonical binary representation of the interchanged object is suitable 
for many classes of interchanged objects. Class objects, i.e., objects of class "Class", define built-in classes 
as well as user-defined classes, as described more completely below and in Appendix A, and do not vary from 
engine to engine within computer network 1500. Class objects are therefore interchanged objects. 

The use of digests to reduce the amount of data transferred, and therefore to reduce the time required to 

45 transport an agent and the objects contained by that agent from one place to another, is illustrated by logic 
flow diagrams 2400 and 2450 (Figures 24A and 24B). 

Logic flow diagram 2400 (Figure 24A) represents the process of transporting agent 1 50A (Figure 1 5A) and 
the objects contained by agent 150A from a source engine 132A to a destination engine 132B when inter- 
changed objects are considered. An agent "contains" all objects owned by the agent as well as every class of 

so which the agent is a member and every class of which any object owned by the agent is a member. As described 
above, agent 150A and all objects contained by agent 150A are packaged into a shipping box, encoded and 
transported to engine 132B. In packaging agent 150Aand objects contained therein, source engine 132A col- 
lects all objects contained by agent 150A in step 2402 (Figure 24A). Processing transfers from step 2402 to 
for each object step 2404 which, with next step 1412, defines a loop wherein each object collected in step 2402 

55 is considered. Processing transfers from for each object step 2404 to digest test step 2406 in which the class 
membership of each object contained by agent 1 50A is checked to determine whether each object has a digest. 

As discussed above and in greater detail in Appendices A and E. members of mix-in class "Interchanged" 
can include a digest. Therefore, if an object has a digest, the object is an interchanged object. If an interchanged 
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object does not have a digest, i.e., if attribute "digest" of the interchanged object is a nil, the interchanged object 
is not interchanged but is instead treated as a non-interchanged object. 

If an object has no digest, even if the object is an interchanged object, processing transfers from digest 
test step 2406 to step 2410 in which the object is encoded according to the encoding rules of Appendix B and 
5 included in the shipping box. Otherwise, if the object has a digest, processing transfers from digest test step 
2406 to step 2408 in which the digest of the object and a citation of the class of which the object is an instance 
are encoded according to the encoding rules of Appendix B and included in a parts box which is in turn included 
in the shipping box. 

Processing transfers from step 2408 or step 2410 to next step 2412 in which processing is transferred to 
10 for each object step 2404. Engine 1 32A repeats the process of steps 2406, 2408 and 241 0 for each object con- 
tained by agent 150A in a loop defined by for each object step 2404 and next 2412. If all objects collected in 
step 2402 have been processed according to the loop of for each object step 2404 and next object step 2412, 
processing transfers from for each object step 2404 to a transfer out encoded agent step 2414. 

In transfer out encoded agent step 2414, the shipping box is encoded and is transported by source engine 
15 132A to destination engine 132B, as described above. Thus, the encoded agent which is transported to des- 
tination engine 132B includes all objects contained by the agent which have no digests and the digests of all 
objects contained by the agent which are interchangeable and which have digests. Transfer out encode agent 
step 2414 is represented in double boxes to indicate interaction between engines across the network. Such 
an exchange of binary data between engines is discussed above and in Appendices C and F. 
20 Logic flow diagram 2450 (Figure 24B), illustrates the transfer of encoded agent 150A from the perspective 

of destination engine 1 32B. Destination engine 1 32B receives the encoded agent as binary data from source 
engine 132A in transfer in encoded agent step 2452. As described above in the context of Figures 15A-15E, 
the encoded agent can pass through one or more intermediate engines, e.g., engine 1 32Z, enroute from engine 
132Ato engine 132B. 

25 Processing transfers from transfer in encoded agent step 2452 to step 2454 in which the encoded agent 

is decoded, thereby reconstructing the shipping box whose contents are the agent objects contained by the 
agent. Each of the objects, which do not have digests and which are contained by the agent, and the digests 
of the interchanged objects contained by the agent which have digests, are processed by destination engine 
1 32B according to the loop formed by for each object step 2456 and next step 2462. Each iteration of the loop 

30 processes one of the objects decoded in step 2454. 

Processing transfers from for each object step 2454 to digest test step 2464. In digest test step 2464, des- 
tination engine 1 32B determines whether an object is a digest. If the object is not a digest, processing transfers 
from digest test step 2464 directly to next object step 2462. Conversely, if * object is a digest, processing 
transfers from digest test step 2464 to test step 2466 and the object is callt ne subject digest". In test step 

35 2466, destination engine 132B determines whether the subject digest is equivalent to a digest of an inter- 
changed object which is present in engine 132B. The method by which such a determination is made is dis- 
cussed in more detail below. 

If an interchanged object having an equivalent digest is found in step 2466, processing transfers from test 
step 2466 to substitute step 2468. In substitute step 2468, the interchanged object is substituted for the subject 

40 digest by replacing all references within the objects decoded in step 2454 to the interchanged object repre- 
sented by the subject digest with references to the found interchanged object. Processing transfers from sub- 
stitute step 2468 to next object step 2462. 

If, on the other hand, no interchanged object having an equivalent digest is found in test step 2466, proc- 
essing transfers from test step 2466 to step 2470. In step 2470, the subject digest is added to a list of digests. 

45 A new list is created if no such list exists. Processing transfers from step 2470 to next step 2462. 

From next step 2462, processing transfers to for each object step 2456. If all objects decoded in step 2454 
have been processed according to the loop of for each object step 2456 and next step 2462, processing trans- 
fers from for each object step 2456 to a list test step 2476, which is described below. 

An engine searches for equivalent interchangeable objects in step 2466 as follows. Each engine contains 

50 one or more places which can exchange equivalent interchangeable objects. Each such place includes a "re- 
pository" of interchangeable objects which are present within the place. Dictionary 2490 (Figure 24D) is the 
repository of place 220B (Figure 15D). The keys of dictionary 2490 (Figure 24D) are classes, i.e., classes 
2490K1, 2490K2, 2490K3 and 2490K4. Associated with each class is a dictionary; for example, associated 
with classes 2490K1-2490K4 are dictionaries 2490A, 2490B, 2490C and 2490D, respectively. 

55 Each of dictionaries 2490A-2490D have the same general organization; dictionary 2490A is illustrative. 

The keys of dictionary 2490Aare digests, i.e.. digests 2490AK1 , 2490AK2 and 2490AK3. Associated with each 
digest is an interchanged object whose digest is the associated digest; for example, associated with digests 
2490AK1-2490AK3 are interchanged objects 2490AV1, 2490AV2 and 2490AV3, respectively. 
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An interchanged object is retrieved from dictionary 2490 in two steps. As discussed above, both a digest 
and a citation of a class are used within a parts box to represent an interchanged object. In the first step, a 
citation is used to retrieve the dictionary of dictionaries 2490A-2490D which is associated with the class ref- 
erenced by the citation. For example, if the citation references class 2490K1, dictionary 2490A is retrieved. 

5 In the second step, the retrieved dictionary is searched for an association between a digest equivalent to 

the digest which is included in the parts box and an interchanged object. If an association is found, the inter- 
changed object is retrieved. If no association is found, the place contains no interchanged object which is equiv- 
alent to the interchanged object represented by the citation and digest in the parts box. Thus, a repository such 
as dictionary 2490 (Figure 24D) is used to determine whether a place contains an equivalent interchanged ob- 

w ject and to retrieve such an object. 

As described above, processing transfers from for each object step 2456 to list test step 2476. In list test 
step 2476, the destination engine, e.g. engine 132B. determines whether a list of digests was created in step 
2470 and, if so. whether the list is empty. If the list of digests does not exist or is empty, processing transfers 
from list test step 2476 to activate traveling agent step 2478 in which engine 132B activates traveling agent 

15 150A by scheduling agent 150A for execution. Processing transfers from activate traveling agent step 2478 
to terminal step 2479 in which the transfer of agent 1 50A, as carried out by engine 1 32B, completes success- 
fully. 

If, on the other hand, a list was created in step 2470 and the list contains at least one digest, an equivalent 
object for at least one interchanged object is not found within destination engine 1 32B and processing transfers 

20 from list test step 2476 to hold traveling agent step 2471. In hold traveling agent step 2471. traveling agent 
150A is held in a suspended state in a holding queue within engine 132B. Processing transfers from hold trav- 
eling agent step 2471 to step 2472. 

In step 2472, the destination engine, e.g. engine 132B. creates an object retrieval agent, i.e., an "ORA". 
The ORA retrieves interchanged objects from the source engine, e.g., engine 132A according to logic flowdi- 

25 agram 2480 (Figure 24C). Processing transfers from step 2472 to step 2474 in which the ORA is directed to 
perform operation "live", thereby initiating interpretation of the ORA. As discussed below in greater detail, the 
central activity of the ORA is shown by logic flow diagram 2480 (Figure 24C). Processing transfers from step 
2474 to terminal step 2479 in which the transfer of agent 1 50A, as carried out by engine 1 32B, completes suc- 
cessfully. It should be noted that traveling agent 150A is not activated and is in the form of a shipping box. 

30 Agent 150A is reconstituted from the shipping box and reactivated by the ORA as described below._- 

Logic flow diagram 2480 (Figure 24C) illustrates the central procedure of the ORA. In step 2482, the ORA 
travels to the source engine, e.g., engine 132A, by performance of operation "go". Processing transfers from 
2482 to step 2484 in which the ORA collects from an interchanged object repository, such as dictionary 2490 
(Figure 24D), within engine 1 32A a copy of each object having a digest that is equivalent to a digest contained 

35 in the list of digests. Processing transfers from step 2484 to step 2485. 

In step 2485, the ORA travels back to the destination engine, e.g., engine 132B, by performance of oper- 
ation "go". The ORA carries to the destination engine copies of those objects whose digests are contained in 
the list of digests, namely, those objects for which there are no equivalent objects within the destination engine. 
Processing transfers from step 2485 to step 2486. In step 2486, the ORA substitutes the objects collected for 

40 the digests within agent 150A as described above. Processing transfers from step 2486 to activate traveling 
agent step 2487, in which agent 1 50A is reconstituted from the shipping box and activated as described above. 
The reconstitution of an agent and the objects contained by the agent from a shipping box is described in great- 
er detail in Appendix D. Processing transfers from step 2487 to terminal step 2488 in which the central proce- 
dure of the ORA is successfully completed. 

45 Thus, efficiency is achieved by transporting across network communications media only those inter- 

changed objects which are not equivalent to interchanged objects within the destination engine. 

Operation "Send " 

50 An agent is capable of traveling to several places simultaneously by performing operation "send". Figure 

25 shows the state of network 2500 prior to performance of operation "send" by agent 150A. In the example 
of Figure 25, agent 150Ain data portion 132A-D of engine 132A is configured to transport a clone of itself to 
place 220B in data portion 132B-D of engine 132B and a clone of itself to place 220C in data portion 132C-D 
of engine 132C simultaneously. In other words, agent 150A is performing operation "send", supplying as the 

55 argument to operation "send" a list of two tickets specifying places 220B and 220C as destination places for 
clones of agent 1 50A. A clone of agent 1 50A is a copy of agent 1 50A which is made by replicating agent 1 50A, 
including the execution state of agent 150A, to form the copy and which is made "active" by assigning a new 
name and identifier to the copy and scheduling the copy for execution by an engine. Clones are described in 
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greater detail in Appendix A. 

The interface of operation "send" is illustrated by Figures 26A, 26B and 26C. Figure 26A illustrates frame 
2602, which records the dynamic state of operation "send" as performed by agent 150Aand which is a part of 
the execution state of agent 150A, immediately prior to performance of operation "send". The execution state 
5 of a process, including an agent, is described in greater detail below and in Appendices A and B. 

Included in frame 2602 is stack 2604. Stack 2604 is the stack from which arguments are popped and to 
which a result is pushed during performance of operation "send". Stack 2604 is therefore the "current stack" 
in the context of operation "send". The "current stack" is defined and explained more completely below and in 
Appendices A and B. 

10 At the top of stack 2604, as indicated by letter "T", is list 2606 whose items are tickets 2608 and 2610. 

Tickets 2608 and 2610 of list 2606 each define a trip to be taken by a corresponding clone of agent 150A. 

Objects 2618 and 2620 are property "travelNotes" of tickets 2608 and 2610, respectively. Objects 2618 
and 2620 provide a mechanism by which respective clones created by performance of operation "send" can 
be distinguished. For xample, in forming tickets 2608 and 2610, agent 150A can store within objects 2618 

15 and 2620 strings whose respective texts are "Able" and "Baker". In such a case, the clone of agent 1 50A cor- 
responding to ticket 2608 retrieves the string "Able" from property "travelNotes" of ticket 2608. Similarly, the 
clone of agent 150A corresponding to ticket 2610 retrieves the string "Baker" from property "travelNotes" of 
ticket 2610. 

The particular implementation by which the respective clones are distinguished is ultimately up to the user 
20 of the present invention. The following is another example. Stored within object 261 8 is an integer whose value 
is one, thereby representing the position of corresponding ticket 2608 within list 2606. Similarly, stored within 
object 2620 is an integer whose value is two, thereby representing the position of corresponding ticket 2610 
within list 2606. 

Permits 2622 and 2624 are properties "destinationPermit" of tickets 2608 and 2610, respectively. Integers 

25 2 6 26 and 2628 are properties "charges" of permits 2622 and 2624, respectively. 

Permit 261 2 is property "permit" of agent 1 50A and therefore represents a part of the internal state of agent 
150A. As described above and in Appendix A. permit 2612 limits the execution of agent 150A. Boolean 2614 
is property "canSend" of permit 2612. If the value of boolean 2614 is "false", operation "send" fails and throws 
an exception of class "Permit Violated". Property "charges" of permit 2612 is integer 2616. As discussed in 

30 greater detail in Appendix A, integer 2616 represents the processing allowance of agent 150A. 

In the example of Figure 25, agent 150A, whose current location is place 220A, is configured to transport 
respective clones of agent 150A to places 220B and 220C. As agent 150A sends a clone of itself to each des- 
tination place defined by a ticket in list 2606 (Figure 26A). performance of operation "send" eventually creates 
as many clones of agent 150A as there are tickets in list 2606. Figures 27A and 27B illustrate a simple em- 

35 bodiment of operation "send" wherein engine 1 32A (Figure 27A) creates within data portion 1 32A-D a number 
of clones of agent 1 50A equal to the number of tickets in list 2606 (Figure 26A). In this example, list 2606 (Figure 
26A) contains two tickets, i.e.. tickets 2608 and 261 0. Therefore, engine 1 32A creates two clones, agent 1 50A- 
1 and agent 150A-2, of agent 150A(Ftgure 27B). Amore efficient embodiment, in which cloning of the respond- 
ing agent is deferred, is described below. 

40 in forming the clones of agent 150A. permits 2622 and 2624 are made property "permit" of the clones cre- 

ated. In other words, permit 2622 is property "permit" of agent 1 50A-1 and permit 2624 is property "permit" of 
agent 150A-2. In creating agents 150A-1 and 150A-2, the allowances of permits 2622 and 2624 are subtracted 
from the corresponding allowances of permit 2512 of agent 150A, i.e.. the agent that is being cloned. In other 
words, the value of integers 2626 and 2628 are subtracted from integer 261 6, which is the charges allowance 

45 of agent 1 50A, i.e., property "charges" of the permit of agent 1 50A. upon creation of agents 1 50A-1 and 1 50A- 
2. If integer 261 6 is not greater than or equal to the sum of integers 2626 and 2628. operation "send" fails and 
throws an exception of class "Permit Violated" since the charges allowance of agent 1 50A is less than the sum 
of the charges allowances of the clones created from agent 1 50A. 

Thus, the permits which are part of the tickets supplied as arguments to operation "send" form the native 

50 permits of the clones created in performance of operation "send". As tickets 2608 and 261 0 define trips to be 
taken by respective clones of agent 150A, permits 2622 and 2624 are property "permit" of tickets 2608 and 
2610, respective, and are therefore also the local permits of respective clones of responding agent 150A. 

In a second embodiment of the present invention, operation "send" consumes, as an argument in addition 
to list 2606, an integer (not shown). In creating clones of responding agent 150A, respective native permits 

55 are formed as described above with the exception that property "charges" of each native permit is initially equal 
to the integer consumed. 

A third embodiment of the present invention is the same as the second embodiment described above with 
the exception that a list of integers is consumed in lieu of a single integer. Additionally, property "charges" of 
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each native permit, which is derived from property "permit" of a ticket within list 2606 (Figure 26A), is initially 
equal to the integer at a position within the consumed list of integers that is equal to the position within list 
2606 of the ticket from which the native permit is derived. For example, property "charges" of the native permit 
of the clone corresponding to ticket 2608 at position one within list 2606 is initially equal to the integer at position 

5 one in the consumed list of integers (not shown). Similarly, property "charges" of the native permit of the clone 
corresponding to ticket 2610 at position two within list 2606 is initially equal to the integer at position two in 
the consumed list of integers. 

In a fourth embodiment of the present invention, operation "send" consumes, as an argument in addition 
to list 2606, a permit (not shown). In creating clones of responding agent 150A. each respective native permit 

10 is a copy of the consumed permit. 

A fifth embodiment of the present invention is the same as the fourth embodiment described above with 
the exception that a list of permits is consumed in lieu of a single permit. Additionally, each native permit of a 
respective clone corresponding to a ticket within list 2606 (Figure 26A) is initially equal to the permit at a position 
within the consumed list of permits that is equal to the position within list 2606 of the ticket to which the clone 

15 corresponds. For example, the native permit of the clone corresponding to ticket 2608 at position one within 
list 2606 is initially equal to the permit at position one in the consumed list of permits (not shown). Similarly, 
the native permit of the clone corresponding to ticket 2610 at position two within list 2606 is initially equal to 
the permit at position two in the consumed list of permits. 

In each of the described embodiments, property "charges" of permit 2612, which is the permit of respond- 

20 ing agent 150A. is reduced by the total of respective properties "charges" of the native permits of the clones 
of agent 150A created in performance of operation "send". 

Each clone of agent 1 50A is transported to a place identified by the corresponding ticket as a destination 
place. For example, ticket 2608 identifies place 220B as the destination for agent 150A-1. and ticket 2610 iden- 
tifies place 220C as the destination for agent 150A-2. Each clone travels to its respective destination place 

25 through the cooperation of the source engine 1 32A with a corresponding destination engine, e.g., either engine 
132B or engine 132C. The transportation of an agent clone, e.g. either agent 150A-1 or agent 150A-2, from 
one place to another in performing operation "send" is as described above in detail in conjunction with operation 

go * 

If, in performance of operation "send", agent 150A successfully creates agents 150A-1 and 150A-2, per- 

30 formance of operation "send" by agent 1 50A succeeds even if the transportation of any or all of the agent clones 
fails. If a trip of an agent clone fa'ls. the trip exception is thrown by the agent clone, not the agent which originally 
performed operation "send". 

A portion of the execution state of agent 150A immediately following performance of operation "send"*by 
agent 1 50A is shown in Figure 26B. Stack 2604. which is the current stack as described above, contains a nil 

35 object 2630. A nil object is produced as a result for the original agent, thereby distinguishing the original agent 
from agent clones created in performance of operation "send". 

Figure 26C shows a portion of the execution state of agent 150A-1 after performance of operation "send" 
by agent 150A. The execution state of agent 150A-2 after performance of operation "send" by agent 150A is 
directly analogous to the execution state of agent 150A-1 as described immediately below. 

40 Permit 2622 is property "permit" of agent 150A-1. Stack 2604-1 is a copy of stack 2604 produced in the 

creation of agent 150A-1 . Stack 2604-1 is the current stack of agent 150A-1 . At the top of stack 2604-1 is ticket 
stub 2632. Ticket stub 2632 is the result produced by operation "send" for an agent clone created by perfor- 
mance of operation "send". Ticket stub 2632 is derived from ticket 2608. 

Ticket stub 2632 is a member of a class "Ticket Stub". Ticket stub 2632 has, among other properties, prop- 

•#5 erties "way" and "travelNotes". Ticket 2608 is a member of a class "Ticket". Class "Ticket" is a subclass of class 
"Ticket Stub"; therefore, ticket 2608 has, among other properties, properties "way" and "travelNotes", defini- 
tions of which are inherited from superclass "Ticket Stub". Ticket stub 2632 is derived from ticket 2608 such 
that properties "way" and "travelNotes" of ticket stub 2632 are equal to properties "way" and "travelNotes", 
respectively, of ticket 2608. As discussed above, property "travelNotes" of ticket 2608 (Figure 26A)can be used 

50 to distinguish agent 150A-1 from agent 150A-2. Similarly, the current stack (not shown) of agent 150A-2 con- 
tains a ticket stub (not shown) whose property "travel Notes" is object 2620. 

Figure 28 shows computer network 2500 after operation "send" has been performed by agent 1 50A. Agent 
150A remains in data portion 132A-D of computer process engine 132A. Agent 150A-1 occupies place 220B 
in data portion 132B-D of engine 132B. Similarly, agent 150A-2 occupies place 220C executing in data portion 

55 1 32C-D of engine 1 32C. 

The access of operation "send" is "private" permitting only the responder to request the operation. As dis- 
cussed in greater detail below and in Appendix A, each feature of the present invention has an access which 
specifies under what conditions the feature can be requested. As the access of operation "send" is private. 
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only agent 1 50A can initiate performance of operation "send" by agent 1 50A. Even engine 1 32A cannot initiate 
performance of operation "send" by agent 150A. 

Deferred Cloning 

5 

Substantial savings in the amount of time required to perform operation "send" and in space occupied by 
clones of an agent created during performance of operation "send" are realized by "deferred cloning". Deferred 
cloning occurs when the engine carrying out performance of operation "send" determines that two or more 
clones of the same agent are to be transferred to a single destination engine. In such a case, a single clone 

w is transferred to the destination engine and additional clones are derived from the single clone at the destin- 
ation engine. Figures 29A-29D are illustrative. 

Agent 150A (Figure 29A) occupies place 220A in engine 132A. Engine 132A is a computer process exe- 
cuting within computer system 11 OA (not shown). Agent 150Ais performing operation "send", supplying as the 
argument to the operation a list of three tickets (not shown) specifying places 220B, 220C and 220D as des- 

15 tination places for clones of agent 150A. Engine 132A is in communication with engine 132E across commu- 
nications link 102AE. Communications link 102AE is as described above with respect to communications link 
102A2 (Figure 15A) in conjunction with operation "go". In addition to engine 132A, engine 132E is in commu- 
nication with engines 1 32B and 1 32F across communications link 1 02EBF. Additionally, engine 1 32F is in com- 
munication with engines 132C and 132D across communications link 102FCD. Places 220B, 220C and 220D 

20 are processes interpreted by engines 132B, 132C and 132D, respectively. Thus, for clones of agent 150A to 
reach places 220B. 220C and 220D. each clone must first be transferred to engine 132E. 

Created within engine 132A is a single clone, i.e., agent 150A-1, of agent 150A. The execution state of 
agent 1 50A-1 includes a send frame 2902 as agent 1 50A-1 is performing operation "send". The execution state 
of an agent is discussed in greater detail below and in Appendix A. Send frames are discussed in greater detail 

25 in Appendix B. Send frame 2902 (Figure 30A) includes list of tickets 2904 which includes tickets 2904B, 2904C 
and 2904D which in turn specify places 220B, 220C and 220D, respectively, as destination places. Agent 
1 50A-1 (Figure 29A), the single clone of agent 150A, therefore represents three separate agent clones which 
are to travel to places 220B, 220C and 220D. respectively. 

Encoded agent 150A-1-E (Figure 30B) is the result of encoding agent 150A-1 (Figure 29A) according to 

30 the encoding rules of Appendix B. Included in encoded agent 150A-1-E (Figure 30B) are destinations 150A- 
1-E-D1, 150A-1-E-D2, and 150A-1-E-D3 which define respective transfer destinations of the three clones of 
agent 1 50A (Figure 29A). As all three clones of agent 1 50A are transferred to engine 1 32E. destinations 1 50A- 
1-E-D1, 150A-1-E-D2, and 150A-1-E-D3 (Figure 30B) all define engine 132E as the transfer destination of a 
respective clone of agent 150A (Figure 29A). Engine 132A determines that destinations 150A-1-E-D1, 150A- 

35 1 -E-D2, and 1 50A- 1 -E-D3 (Figure 30B) each define engine 1 32E as a transfer destination and transfers a sin- 
gle clone of agent 150A (Figure 29A). i.e., encoded agent 150A-1-E (Figure 30B) to engine 132E (Figure 29B). 
Thus, rather than transporting three separate clones from engine 1 32A to engine 1 32E. a single clone is trans- 
ported to engine 1 32E reducing proportionally the amount of space within engine 1 32A occupied by clones of 
agent 150A and the amount of time required to transport clones to engine 132E. 

40 Agent 150A-1 is encoded and transferred to engine 132E (Figure 29B) as discussed above in conjunction 

with operation "go". Engine 132E retrieves list 2904 of send frame 2902 of agent 150A-1. As the structure of 
an encoded agent is standardized as described in Appendix B. an engine, e.g., engine 132E. can retrieve list 
2904 without decoding encoded agent 1 50A-1 . Engine 1 32E determines that one clone corresponding to ticket 
2904B of send frame 2902 is to be transported to engine 132B and that two clones corresponding to tickets 

45 2904C and 2904D are to be transported through engine 132F to engines 132C and 132D, respectively. There- 
fore, a second clone, agent 1 50A-2 (Figure 29C). is created from agent 1 50A-1 by engine 1 32E. As agent 1 50A- 
1 is encoded, agent 150A-2, which is a copy of agent 150A-1, is encoded as well. Agent 150A-2 includes send 
frame 2902-2, and send frame 2902-2 in turn includes list of tickets 2904-2. List of tickets 2904-2 includes a 
single ticket 2904B which is removed from list of tickets 2904 of send frame 2902 of agent 150A-1. 

50 Agent 150A-2 is transferred to engine 132B, and agent 150A-1 is transferred to engine 132F (Figure 29D). 

As ticket 2904B specifies place 220B as the destination of a trip and ticket 2904B is the only ticket in send 
frame 2902-2, place 220B is the destination of agent 1 50A-2 and no further clones of agent 1 50A are created 
from agent 150A-2. Agent 150A-2 is decoded by engine 132B. Agent 150A-2 is granted occupancy to place 
220B by performance of operation "entering" by place 220B as described above, and performance of operation 

55 "send" for agent 150A-2 is completed. Send frame 2902B is therefore removed from the execution state of 
agent 150A-2 as discussed below in the context of the execution model. 

Agent 150A-1 is transferred to engine 132F. Included in send frame 2902. which is part of the execution 
state of agent 1 50A-1 , is list of tickets 2904 which in turn includes tickets 2904C and 2904D. Thus, agent 1 50A- 
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1 represents two clones of agent 150A which are traveling to places 220C and 220D, respectively. Therefore, 
by transferring a single clone, i.e. agent 150A-1, from engine 132E to engine 132F, substantial savings are 
realized in storage space in engine 132E and in time required to transport data between engine 132E and en- 
gine 132F as described above. 

5 In the manner described above, in engine 1 32F (i) a third clone of agent 1 50A. i.e., agent 1 50A-3. is formed 

from agent 1 50A- 1 , and (ii) a send frame (not shown) is included in agent 1 50A-3 which includes ticket 2904C. 
As agent 150A-1, from which agent 150A-3 is copied, is encoded, agent 150A-3 is encoded as well. Ticket 
2904C is removed from send frame 2902 of agent 150A-1. Agent 150A-3 is transferred to engine 132C, and 
agent 150A-1 is transferred to engine 132D (Figure 29E). 

w Engine 1 32C includes place 220C which is the trip destination of agent 1 50A-3 as defined by ticket 2904C, 

and engine 1 32D includes place 220D which is the trip destination of agent 1 50A-1 as defined by ticket 2904D. 
In the manner described above, (i) engine 1 32C decodes agent 1 50A-3 and agent 1 50A-3 is granted occupancy 
of place 220C by performance of operation "entering" and (ii) engine 132D decodes agent 150A-1 and agent 
150A-1 is granted occupancy of place 220D by performance of operation "entering". Since send frame 2902 

15 (not shown) contains only a single ticket which specifies place 220D as the destination, operation "send" com- 
pletes for agent 150A-1. Similarly, as agent 150A-3 includes a send frame specifying a single place, namely, 
place 220C which is the place occupied by agent 150A-3, as the destination of a trip, operation "send" com : 
pletes for agent 150A-3 as well. 

Each of agents 150A-1. 150A-2 and 150A-3 completes performance of operation "send" having an exe- 

20 cution state which includes a send frame which includes a single ticket which defines the trip taken by the re- 
spective agent clone. The respective single ticket is used as described above to derive a ticket stubwhich is 
produced as the result of the respective agent's performance of operation "send". 

Thus, substantial amounts of computer storage space and time are saved in performance of operation 
"send" by deferring cloning as long as possible in the transportation of the several clones to respective des- 

25 tination places. 

The structure of send frame 2902 during transport of agent 150A-1 is shown in Figure 30. Class "Send 
Frame" defines property "tickets". Property "tickets" of send frame 2902 is list 2904 whose items are tickets 
2904B. 2904C and 2904D. Tickets 2904B, 2904C and 2904D define respective trips to be taken by respective 
clones of responding agent 150A. 

30 As discussed above, performance of operation "send" by agent 150A creates one or more agent clones, 

each agent clone representing one or more clones of agent 150A. If forming each agent clone, e.g. agent 150A- 
1 (Figure 29A), a copy of send frame 2902 is included in the agent clone. Property "tickets" of the send frame 
copy is modified so as to include only those tickets corresponding to the clones represented by the agent clone. 
For example, agent 150A-2 (Figure 29C) includes send frame 2902-2 which in turn includes ticket 2904B and 

35 agent 150A-1 includes send frame 2902 which in turn includes tickets 2904C and 2904D. Therefore, agent 
1 50A-2 represents a single clone of agent 1 50A which is traveling to the place specified by ticket 2904B, name- 
ly, place 220B. Similarly, agent 150A-1 represents two clones of agent 150A which are traveling to places spe- 
cified by tickets 2904C and 2904D, namely, places 220C and 220D. respectively. 

Once each clone has reached its respective destination, property "tickets" of send frame 2902 (Figure 

40 30) is a list of exactly one ticket. For example, agents 150A-1, 150A-2 and 150A-3 (Figure 29E) include send 
frames 2902, 2902-2 and 2902-3, respectively, which each include a single ticket, namely, respective tickets 
2904D, 2904B and 2904C. Thus, each send frame contains the single ticket defining the trip taken by the cor- 
responding agent clone. The single ticket is used as described above to form a ticket stub which is produced 
as a result by performance of operation "send" by each respective agent clone. 

45 Thus, substantial savings are realized in computer storage space and data transportation time by deferring 

cloning of an agent performing operation "send" as long as two or more agent clones are taking trips which 
are coextensive in part. As described above in the context of operation "go", if an exception is thrown during 
performance of operation "go" by an agent, the agent can be placed in purgatory. Similarly, if an exception is 
thrown during performance of operation "send" by an agent clone, the agent clone can be placed in purgatory. 

so Additionally, if transportation of multiple clones of an agent which are represented by a single encoded agent, 
e.g. agent 150A-1 (Figure 29B), fails, each clone represented by the encoded agent is decoded, activated, and 
placed in purgatory as described above. 

Interaction Between Agents: Operation "Meet" 

55 

Two agents, which occupy the same place, are capable of interacting with one another by one agent re- 
questing that the other perform an operation, or set or query an attribute. Information is exchanged between 
the two agents through the arguments and result of the operation requested or through the attribute which is 
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set or queried. For example, agent 150Aand 150B occupy place 220B which is executing within engine 132B 
(Figure 15E). Therefore, agent 150A and agent 150B are capable of interacting by (i) agent 150A requesting 
that agent 150B perform a feature or by (ii) agent 150B requesting that agent 150A perform a feature. 

Agent 1 50A is capable of requesting that agent 1 50B perform a feature only if agent 1 50A contains a ref- 
5 erence to agent 150B. Similarly, agent 150B is capable of requesting that agent 150A perform a feature only 
if agent 1 50B contains a reference to agent 1 50A. Agent 1 50A obtains a reference to agent 1 SOB by requesting 
performance of operation "meet" by a meeting place of which agents 150A and 150B are occupants. To this 
point, place 220B has only been described as a place occupied by agents 150Aand 150B. For purposes of 
the following discussion, place 220B is a meeting place, i.e., a member of class "Meeting Place". Meeting places 
10 are discussed in more detail in Appendix A. 

Figures 31 A and 31 B illustrate the interface of operation "meet". Frame 31 00 is part of the execution state 
of agent 150A. Frame 3100 records the state of the performance of operation "meet" by meeting place 220B. 
Meeting place 220B is identified within the execution state of agent 150Aas the responder of operation "meet". 

Frame 3100 includes stack 31 02, which is the current stack. Immediately prior to performance of operation 
15 "meet" (Figure 31 A), stack 3102 contains, at its top, petition 3106. Petition 3106 is an argument consumed by 
performance of operation "meet". Petitions, i.e. members of class "Petition", are discussed more completely 
below and in Appendix A. 

Logic flow diagram 3200 (Figure 32) shows the implementation of operation "meet" as performed by meet- 
ing place 220B. Engine 132B (Figure 15E), in carrying out operation "meet" as performed by meeting place 

20 220B. determines the petitioned agent by parsing petition 3106 (Figure 31A). Petition 3106 specifies a peti- 
tioned agent by name, by class or by both. A petitioned agent is an agent specified by a petition as the agent 
with which an agent requesting a meeting is configured to meet. 

Engine 132B pops petition 31 06 from the cue-- it stack in a pop petition step 3202 (Figure 32). Processing 
transfers from pop petition step 3202 to a step 3204. In step 3204. engine 132B creates a new, empty list of 

25 telenames. The telenames of the list created in step 3204 are telenames of petitioned agents which have re- 
jected a meeting with the requesting agent. The list is initially empty as initially no petitioned agent has rejected 
a meeting with the requesting agent. 

Processing transfers from step 3204 to a find petitioned agent step 3206 in which the engine carrying out 
performance of operation "meet", e.g.. engine 132B (Figure 15E), finds a petitioned agent, i.e., an agent which 

30 satisfies petition 3106 (Figure 31 A), whose telename is not an item of the list of telenames created in step 3204 
(Figure 32). An agent satisfies petition 3106 (Figure 31 A) as follows. 

As described in greater detail in Appendix A, petition 31 06 includes a property "agentName" and a property 
"agentClass" (neither shown). Both properties "agentName" and "agentClass" are optional and can therefore 
each be a nil. If property "agentName" of petition 3106 is a telename and property "agentClass" is nil, a peti- 

35 tioned agent is an agent whose telename is specified by the telename that is property "agentName" of petition 
3106. If property "agentClass" is a citation and property "agentName" is nil, a petitioned agent is an agent which 
is a member of a class specified by the citation that is property "agentClass" of petition 31 06. If neither property 
is nil. a petitioned agent is an agent which satisfies both criteria. If both properties are nil, an exception of class 
"Meeting Invalid" is thrown, causing operation "meet" to fail. 

40 Processing transfers from find petitioned agent step 3206 to test step 3208 in which engine 132B deter- 

mines whether a petitioned agent is found in find petition agent step 3206. If no petitioned agent is found in 
find petitioned agent step 3206, processing transfers from test step 3208 to a wait step 3222 which is described 
below. Conversely, if a petitioned agent is found in find petitioned agent step 3206. processing transfers from 
test step 3208 to a meeting step 3210. 

45 In meeting step 3210, the petitioned agent is requested to perform operation "meeting" by engine 132B 

which is interpreting meeting place 220B. In performing operation "meeting", the petitioned agent agrees or 
refuses to participate in a meeting with agent 150A. Operation "meeting" is discussed further below and in 
Appendix A. 

After performance of operation "meeting" by the petitioned agent, processing transfers from meeting step 
so 3210 to test step 321 2. In test step 321 2, engine 1 32B determines whether operation "meeting" completed suc- 
cessfully, indicating that the petitioned agent agrees to the meeting. If the petitioned agent refuses the meeting, 
i.e., processing transfers from test step 3212 to a first fully qualified test step 3234, which is described below. 
Conversely, if the petitioned agent agrees to the meeting, i.e., if operation "meeting" completed successfully, 
processing transfers from test step 3212 to a build contact step 3216. 
55 in build contact step 3216, a contact 3108 (Figure 31 B), whose subject is the petitioned agent, is created. 

Processing transfers from build contact step 3216 (Figure 32) to a push contact step 3218 in which contact 
31 08 (Figure 31 B) is pushed on to stack 31 02, thereby producing contact 3108 as a result. Processing transfers 
from push contact step 3218 to terminal step 3220 in which operation "meet" completes successfully. 
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However, as discussed above, if the petitioned agent throws an exception in performance of operation 
"meeting", thereby refusing to meet with agent 150A, processing transfers from test step 3212 to first fully 
qualified test step 3234. In first fully qualified test step 3234, engine 132B determines whether petition 3106 
(Figure 31 A) is fully qualified. Petition 3106 is fully qualified if the telename that is property "agentName" of 

5 petition 3106 is fully qualified. A telename includes both a property "authority" and a property "identity". Tel- 
enames are described more completely in Appendix A. Property "identity" of a telename is optional, i.e., can 
be a nil. If property "identity" of a telename is nil. the telename is partially qualified and denotes all named 
objects of the authority that is property "authority" of the telename. On the other hand, if property "identity" 
of a telename is not nil, the telename is fully qualified and denotes exactly zero or one named object. 

w In first fully qualified test step 3234 (Figure 32), engine 132B determines whether petition 3106 (Figure 

31 A) is fully qualified. If petition 3106 (Figure 31 A) is fully qualified, processing transfers from first fully quali- 
fied test step 3234 to terminal step 3236 in which an exception of class "Meeting Denied" is thrown, causing 
operation "meet" to fail. Thus, if petition 31 06 (Figure 31 A) is fully qualified and the one agent which satisfies 
petition 3106 rejects the meeting, operation "meet" fails. On the other hand, if petition 31 06 is not fully qualified, 

15 processing transfers from first fully qualified test step 3234 to an add agent to list step 3214. 

In add agent to list step 3214, the petitioned agent found in find petitioned agent step 3206 is added to 
the list of telenames created in step 3204. Processing transfers from add agent to list step 3214 to find peti- 
tioned agent step 3206. 

As discussed above, if no petitioned agent is found in find petitioned agent step 3206, processing transfers 
20 from test step 3208 to wait step 3222. In wait step 3222, interpretation of agent 1 50A is suspended until petition 
3106 (Figure 31 A) expires or until an agent enters meeting place 220B. i.e., until meeting place 220B success- 
fully performs operation "entering". As described more completely in Appendix A. petition 31 06 includes a prop- 
erty "maximumWait" which defines a maximum amount of time that can elapse from the start of performance 
of operation "meet" before operation "meet" must conclude, either successfully or otherwise. Petition 31 06 ex- 
25 pires when the amount of time specified in property "maximumWait" has passed since the start of performance 
of operation "wait". 

When petition 31 06 expires or when an agent enters meeting place 220B, interpretation of agent 1 50A re- 
sumes and processing transfers from wait step 3222 (Figure 32) to a timeout test step 3224. In timeout test 
step 3224, engine 132B (Figure 15E) determines whether resumption of interpretation of agent 150A (Figure 

30 31 A) results from expiration of petition 3106. If interpretation of agent 150A is resumed as a result of the^ex- 
piration of petition 3106 (Figure 31 A), processing transfers from timeout test step 3224 (Figure 32) to terminal 
step 3226 in which an exception of class "Petition Expired" is thrown, causing operation "meet" to fail. 

On the other hand, if interpretation of agent 150A (Figure 31 A) is resumed as a result of an agent entering 
place 220B. processing transfers from timeout step 3224 to test step 3228. In test step 3228, engine 132B 

35 (Figure 15E) determines whether the entering agent (not shown) is petitioned, i.e.. satisfies petition 3106 (Fig- 
ure 31 A), and is not on the list of telenames created in step 3204 (Figure 32) . If the entering agent does not 
satisfy petition 3106 (Figure 31 A) or if the telename of the entering agent is an item of the list of telenames 
created in step 3204 (Figure 32). processing transfers from test step 3228 to wait step 3222. 

If. on the other hand, the entering agent satisfies petition 3106 (Figure 31 A) and the telename of the en- 

40 tering agent is not an item of the list of telenames created in step 3204 (Figure 32), processing transfers from 
test step 3228 to a second meeting step 3230. In second meeting step 3230, the entering agent is directed to 
perform operation "meeting". Processing transfers from second meeting step 3230 to test step 3232 in which 
engine 1 32B (Figure 1 5E) determines whether performance of operation "meeting" by the entering agent suc- 
ceeded, the entering agent thereby accepting a meeting with agent 1 50A, or failed, the entering agent thereby 

45 rejecting a meeting with agent 150A. 

If performance of operation "meeting" by the entering agent succeeds, processing transfers from test step 
3232 to build contact step 3216. As described above, in build contact step 3216 and the steps that follow, a 
contact to the petitioned, i.e., entering, agent is built, the contact is pushed on to the current stack, and operation 
"meet" completes successfully. If, on the other hand, performance of operation "meeting" by the entering agent 

50 throws an exception, processing transfers from test step 3232 to a second fully qualified test step 3238. 

In second fully qualified test step 3238, engine 132B (Figure 15E) determines whether petition 3106 (Fig- 
ure 31 A) is fully qualified. If petition 3106 is fully qualified, processing transfers from second fully qualified 
test step 3238 (Figure 32) to terminal step 3240 in which an exception of class "Meeting Denied" is thrown, 
causing operation "meet" as performed by meeting place 220B to fail. 

55 Conversely, if petition 3106 (Figure 31 A) is not fully qualified, processing transfers from second fully quali- 

fied test step 3238 to a second add agent to list step 3242. In second add agent to list step 3242, the telename 
of the petitioned, i.e.. entering, agent is added to the list of telenames created in step 3204. Processing transfers 
from second add agent to list step 3242 to wait step 3222 which is described above. 
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Thus, a meeting is arranged between agent 1 50A and a petitioned agent (i) which is of the name and class 
specified by petition 3106, (ii) which occupies the responding meeting place, and (iii) which agrees to the meet- 
ing within the maximum time period specified in petition 3106. The last condition permits a first agent to request 
a meeting with a second agent which does not occupy the meeting place occupied by the first agent but which 

5 is expected to arrive at the meeting place within a certain amount of time. 

Immediately following performance of operation "meet" (Figure 31 B), stack 3102 contains, at its top, con- 
tact 3108, as described above. Contact 3108 includes a property "subject" which is a reference to agent 150B 
(Figure 15E). Property "subject" of contact 3108 (Figure 31 B) is produced by querying attribute "subject" of 
contact 3108. Attribute "subject" of a contact is described in greater detail in Appendix A. Thus, agent 150A 

w obtains a reference to agent 1 SOB (Figure 1 5E) and is therefore capable of requesting that agent 1 SOB perform 
features. 

As discussed below in the context of operation "meeting", agent 150B consumes, as an argument in per- 
formance of operation "meeting", a contact which identifies agent 150A as the agent requesting a meeting. 
After performance of operation "meet" by meeting place 220B. the contact consumed by agent 1 SOB includes 

15 a property "subject" which is a reference to agent 150 A. Thus, agent 150B obtains a reference to agent 150A 
and is capable of requesting that agent 150A perform features. 

An agent, which is contacted, is a member of a class which inherits from mix-in class. "Contacted". As de- 
scribed more fully in Appendix A below, mix-in class "Contacted" defines attribute "contacts" which provides 
access to property "contacts". Property "contacts" is a set of contacts. Agent 150B (Figure 33) is a contacted 

20 agent and therefore includes property "contacts", which is set 3302. After performance of operation "meet" by 
meeting place 220B as described above, contact 3404, which is the contact consumed in performance of op- 
eration "meeting" by agent 150B, is added to set 3302 by engine 132B. 

Consent of the Petitioned Agent: Operation "Meeting " 

25 

As discussed above, a petitioned agent agrees or refuses to meet with an agent requesting a meeting by 
performance of operation "meeting" by the petitioned agent. Operation "meeting" is not defined or inherited 
by class "Agent". Instead, operation "meeting" is defined by mix-in class "Petitioned". Class "Agent" is not a 
subclass of mix-in class "Petitioned", but subclasses of class "Agent", which are subsequently defined by users 
30 of the present invention, can be subclasses of mix-in class "Petitioned". Thus, only agents which are members 
of such user-defined subclasses can perform operation "meeting" and can therefore participate in meetings 
with other agents. 

Figure 34A shows the execution state of agent 1 50A immediately prior to performance of operation "meet- 
ing" by agent 1 50B. Frame 3400 is a part of the execution state of agent 1 50A and records the dynamic state 
35 of operation "meeting" as performed by agent 150B. Operation "meeting" is requested by engine 132B; the 
performance of "meeting" is recorded in the execution state of agent 150A. The permit of either agent 150A 
or agent 150B, perferably agent 150B. may be debited by performance of operation "meeting". Agent 150B 
(Figure 15E) is identified within engine 132B as the responder of operation "meeting". 

Stack 3402 is property "stack" of frame 3400 and is the current stack. Immediately prior to performance 
40 of operation "meeting", stack 3402 contains, from top to bottom, contact 3404 and petition 3406. 

Contact 3404 identifies agent 150A as the agent requesting a meeting. Property "subjectName" (not 
shown) of contact 3404 is a telename which is equivalent to the telename of agent 150A. thereby identifying 
agent 150Aas the requesting agent. Property "subjectClass" (not shown) of contact 3404 is a citation identi- 
fying the class of which agent 150A is an instance. Property "subject" (not shown) of contact 3404, which is 
45 normally a reference to agent 1 50A, is made nil by engine 132B. Thus, agent 1 SOB, by consuming contact 3404 
in performance of operation "meeting", has all the information necessary to properly identify agent 150Aas 
the agent requesting the meeting, but has no reference to agent 150A and therefore has no way to interact 
with agent 150A. In this way, neither agent can interact with the other until both have agreed to the meeting. 
Petition 3406 is a copy of petition 3106 (Figure 31A) supplied by agent 150A (Figure 15E) in requesting 
50 the meeting, as this argument is passed "byCopy". Passing an argument "byCopy" is discussed in greater detail 
below and in Appendix A. 

Agent 150B agrees to the meeting defined by petition 3406 (Figure 34A) with the agent identified by con- 
tact 3404 by performing operation "meeting" successfully. The meeting is refused by throwing an exception, 
thereby causing operation "meeting" to fail. The method for operation "meeting", as defined by mix-in class 
55 "Petitioned", never succeeds and always throws an exception of class "Meeting Denied". However, subse- 
quently defined subclasses of class "Agent", which inherit from mix-in class "Petitioned" can redefine the im- 
plementation of operation "meeting" so as to succeed under certain circumstances. 

Since agents are anticipated to serve a wide variety of needs and to perform a wide variety of services, 
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the number of subclasses of class "Agent" and the variations of methods for operation "meeting" are quite large. 
For example, logic flow diagram 3500 (Figure 35) shows one such method for operation "meeting". In step 3502, 
contact 3404 (Figure 34A) and petition 3406 are popped from stack 3402. Processing transfers from step 3502 
(Figure 35) to step 3504 in which attribute "subjectClass" of contact 3404 (Figure 34A) is queried, thereby pro- 

5 ducing property "subjectClass" of contact 3404. Processing transfers from step 3504 (Figure 35) to a test step 
3506, in which property "subjectClass" of contact 3404 (Figure 34A) is compared to the citation of a specific 
class. If property "subjectClass" of contact 3404 is equal to the citation, processing transfers from test step 
3506 (Figure 35) to terminal step 3508. In terminal step 3508, operation "meeting" completes successfully and 
the meeting is thereby agreed to. Otherwise, if property "subjectClass" of contact 3404 (Figure 34) is not equal 

10 to the citation, processing transfers from test step 3506 (Figure 35) to terminal step 3510 in which an exception 
of class "Meeting Denied" is thrown causing operation "meeting" to fail, thereby rejecting a meeting with the 
agent identified by contact 3404 (Figure 34A). 

As discussed above, contact 3404, which identifies agent 150Aand is supplied to agent 150B (Figure 15E) 
as an argument in requesting performance of operation "meeting", contains no reference to agent 150A. In- 

15 stead, property "subject" of contact 3404 (Figure 34A) is nil. Once a meeting is successfully arranged by per- 
formance of operation "meet" by meeting place 220B (Figure 15E) as described above, engine 132B modifies 
property "subject" of contact 3404 (Figure 34A) to be a reference to agent 150A. 

Thus, the full generality and data processing capabilities of the computer instruction set described in Ap- 
pendix A can be used to apply sophisticated logic, processing substantial amounts of data, to determine with 

20 which agents and under what circumstances specific agents are configured to agree to a meeting. 

Figure 34B shows the state of frame 3400 immediately following performance of operation "meeting" by 
agent 150B (Figure 15E). Stack 3402 (Figure 34B) is empty as operation "meeting" produces no result. The 
access of operation "meeting" is "system"; only an engine is capable of requesting operation "meeting". It 
should be noted that operation "meeting" defined by mix-in class "Petitioned" is distinct and separate from op- 

25 eration "meet" defined by class "Meeting Place" which is discussed above and in Appendix A. 

Terminating Interaction Between Agents: Operation "Part" 

As described above, two agents exchange references to each other and to objects owned by either agent 

30 during the course of a meeting between the two agents. Terminating interaction between the agents requires 
ensuring that neither agent contains a reference to the other agent or references to objects owned by the other 
agent. Either agent participating in a meeting between two agents occupying a meeting place can terminate 
the meeting by requesting performance of operation "part" by the meeting place. Agents 150Aand 150B which 
occupy meeting place 220B and which are interpreted by engine 132B (Figure 15E), are shown in Figure 36. 

35 Agent 150A has obtained reference 150A-R1 to agent 150B, and agent 150B has obtained reference 150B- 
R1 to agent 150A, by the successful performance of operation "meet" by meeting place 220B. Object 3602 is 
owned by agent 150A. Similarly, object 3604 is owned by agent 150B. Figure 36 shows the state of agents 
150A and 150B after agents 150A and 150B have interacted and exchanged references to objects 3602 and 
3604. By giving to agent 1 SOB a reference to object 3602, agent 150Agrants agent 150B access to object 3602. 

40 Such access by references 150B-R1 and 150B-R2 enables agent 150B to issue instructions to engine 132B 
which cause agent 150Aand object 3602, respectively, to take action in accordance with the instructions is- 
sued. Similarly, agent 1 50B gives to agent 1 50A reference 1 50A-R2 to object 3604, thereby granting to agent 
1 50A similar access to object 3604. 

Agent 150A contains references 150A-R1, 150A-R2 and 150A-R3 to agent 150B. object 3604, and object 

45 3602, respectively. References 1 50A-R1 , 1 50A-R2 and 1 50A-R3 are (i) contained either within a stack or within 
a list of variables (neither shown) of a frame (also not shown) which is part of the execution state of agent 1 50A 
or (ii) stored as a property, or as a component of a property, of agent 150A. The execution state of an agent 
is discussed in detail below. Agent 150B similarly contains references 150B-R1, 150B-R2 and 150B-R3 to 
agent 150A. object 3602, and object 3604. respectively. By giving to agent 1 50A reference 150A-R2 to object 

50 3604. agent 1 SOB allows agent 1 50A (i) to request that object 3604 perform an operation or (ii) to copy a portion 
or all of object 3604. 

Either agent 150A or agent 150B is capable of terminating the interaction between agents 150Aand 150B 
by requesting that meeting place 220B perform operation "part". For illustration purposes, agent 150A is the 
agent which requests that meeting place 220B perform operation "part". Figures 37A and 37B illustrate the 
55 state of agent 1 50A immediately prior to and following , respectively, performance of operation "part" by meeting 
place 220B. Frame 3702 is a part of the execution state of agent 1 50A and records the state of operation "part" 
as performed by meeting place 220B. Meeting place 220B is property "responder" of frame 3702 and is there- 
fore the responder of operation "part". Stack 3704 is property "stack" of frame 3702, which is also part of the 
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execution state of agent 150A, and is the current stack. 

At the top of stack 3704 is contact 3706. Contact 3706 identifies agent 1 SOB as the agent from which agent 
1 50A is to part. Engine 1 32B (Figure 1 5E), in carrying out performance of operation "part" on behalf of meeting 
place 220B. directs agent 150B to perform operation "parting". Agent 150B consumes as the sole argument 

5 a contact identifying agent 150Aas the agent with whom agent 150B is parting. Property "subject" of the con- 
tact, which is usually a reference to agent 1 50A is voided by engine 1 32B prior to requesting operation "parting" 
so that agent 150B is not left with a reference to agent 150A after the meeting is terminated. 

In performing operation "parting", agent 150B produces no result. The dynamic state of performance of 
operation "parting" is not part of the execution state of either agent 150B (Figure 15E) or agent 150A, but is 

w instead part of the execution state of an engine process. Any exception thrown by performance of operation 
"parting" is not experienced by, and therefore has no effect upon, either agent 150B or agent 150A. In per- 
forming operation "parting", agent 1 SOB is notified that agent 1 SOAhas terminated the meeting between agents 
150A and 150B. If agent 150B is a contacted agent, the item of property "contacts" of agent 150A that is the 
contact referencing agent 150A is removed from property "contacts" of agent 150B. The access of operation 

is "parting" is "system"; therefore, only engine 132B can request that agent 150B perform operation "parting". 

Figure 37B illustrates the state of agent 150A immediately following performance of operation "part" by 
meeting place 220B. Stack 3704 is empty as operation "part" produces no result. 

Terminating a meeting between agents ISOAand 150B voids all references in agent 150Ato agent 150B 
and all objects owned by agent 150B. For example, in Figure 38, reference 150A-R1 that previously identified 

20 agent 150B and reference 150A-R2 that previously identified object 3604 are voided. Similarly, reference 
1 50B-R1 that previously referenced agent 1 50A and reference 1 50B-R2 that previously referenced object 3602 
are voided within agent 150B as well. Thus, agents 150A and 150B are no longer capable of exchanging in- 
formation. If agents ISOAand 150B are contacted agents, a contact identifying agent 150A is removed from 
property "contacts" of agent 150B, and a contact identifying agent 150B is removed from property "contacts" 

25 of agent 150A. 

Applicability of the Present Invention to Large. Wide-Area Networks 

Thus far, a communications system is disclosed in which agent 150A (Figure 15A) transports itself, or a 

30 clone of itself, to meeting place 220B, which is occupied by agent 150B, by performance of operation "go" or 
operation "send", respectively. Agent 150A then requests performance of operation "meet" by meeting place 
220B to arrange a meeting between agent ISOAand agent 150B. During the meeting, agents 150A and 150B 
are capable of exchanging information as described in greater detail below. 

While the foregoing discussion pertains to a very simple use of the present invention, much more general 

35 uses can be made of the present invention. Through application of the set of computer instructions described 
herein and in Appendix A, an agent is capable of applying sophisticated and complex logic to determine to what 
places to transport itself and with which other agents and places to meet and exchange information. 

Additionally, the present invention is not limited to networks of two or three computer systems, as described 
herein, and as previously stated, the present invention is not limited to homogenous networks. The set of com- 

40 puter instructions described herein and in Appendix A can be used to create and position places throughout a 
large area network such that agents can be created which travel throughout the large area network. As the 
disclosed instruction set can be implemented in heterogenous networks, the wide area network can include 
a wide variety of computer systems including large, mainframe computers; local area networks; and small per- 
sonal computers through which an agent in the wide area network can travel. 

45 Furthermore, while a meeting is defined as an interaction between two agents, an agent is capable of par- 

ticipating in any number of meetings simultaneously and is therefore capable of interacting with a multitude 
of agents simultaneously, as long as those agents occupy the same meeting place occupied by the first- 
mentioned agent. 

50 Interaction between Agents: Introduction to the Execution Model 

During a meeting between agent 1 50A and agent 1 SOB, agent 1 50A (Figure 1 5E) interacts with agent 1 SOB 
by issuing an instruction directing agent 150B to perform a feature. The following describes the mechanism 
by which performance of a feature is requested; this mechanism is discussed in greater detail below and in 
55 Appendix A. 

An execution state is associated with each process. As discussed above in the Glossary of Terms, each 
method has a dynamic state during performance of the method. The execution state of a process includes one 
or more frames, each frame recording the dynamic state of a method which is part of the execution state of 
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the process. Within each frame is a stack on to which arguments are pushed prior to requesting operations, 
and from which results are popped after performance of operations. The stack of the current frame is the cur- 
rent stack. The current frame is the frame which contains the computer instruction whose execution is currently 
being carried out by an engine. 
5 Prior to requesting an operation, the requester pushes on to the current stack references to zero or more 

objects which are thereby supplied as arguments for the operation. The requester then pushes on to the current 
stack a reference to the responder. The responder is the object which is directed by the requester to perform 
the requested operation. Finally, the requestor requests the execution of an identifier which identifies the re- 
quested operation. 

10 In carrying out performance of the requested operation, an engine pops an object from the top of the cur- 

rent stack, and the object is made the responder of the operation. A method implementing the operation is found 
within the classes of which the responder is a member and performed. In one embodiment, performance of 
the method (i) forms a new stack, (ii) pops the arguments of the operation from the current stack and pushes 
them on to the new stack, (iii) makes the new stack current, (iv) pops arguments from the new current stack, 

15 (v) pushes a result, if one is produced by the operation, on to the new current stack, and (vi) pops the result, 
if any, from the new current stack and pushes the result, if any, on to the previously current stack. The execution 
of operations, and features in general, is discussed in greater detail below and in Appendix A. 

The following example illustrates the mechanism by which operations are requested. As discussed above, 
during the course of a meeting, agent 150A interacts with agent 150B by directing agent 150B to perform an 

20 operation. Agent 150A grants agent 1508 access to objects contained within agent 150A by supplying those 
objects as arguments to the operation requested. Agent 1 SOB grants agent 1 50A access to an object contained 
within agent 150B by producing that object as a result of the requested operation. 

Figures 39A-39F illustrate an example of agent 150A (Figure 15E, not shown in Figures 39A-39F) inter- 
acting with and passing information to agent 150B. 

25 Figure 39A shows empty stack 3902. Stack 3902 is the current stack of the execution state of agent 1 50A 

(not shown). While Figure 39A shows stack 3902 as being empty, such need not be the case. However, no 
objects on stack 3902 in Figure 39Aare affected by this example. String 3904 whose text is "this is a message" 
is pushed on to stack 3902 (Figure 39B). A reference to agent 150B is pushed on to stack 3902 (Figure 39C). 
Agent 150A next executes an identifier whose text is "store" and which references an operation "store". 

30 In execution of the identifier, an object, i.e. agent 150B. is popped from stack 3902 and the object is directed 
to perform operation "store" (Figure 39D). In this example, operation "store" is defined for a class of which agent 
150B is a member and whose method is represented by logic flow diagram 4000 (Figure 40). 

In performing operation "store", agent 150B pops string 3904 from stack 3902 in step 4002 (Figure 40). 
Although agent 150B is described as performing operation "store", the frame (not shown) which records the 

35 dynamic state of agent 150B's performance of operation "store" is part of the execution state of agent 150A 
(not shown). The charges allowance, i.e., property "charges", of the permit of agent 1 50A is therefore debited 
for processing resulting from performance of operation "store" by agent 150B. Agent 150B is the object per- 
forming operation "store" since (i) the execution state of agent 1 50A (not shown) identifies agent 1 SOB as the 
responder and since (ii) the method of operation "store" is provided by a class of which agent 1 SOB is a member 

40 and (iii) the internal state of agent 150B provides a context within which operation "store" is performed. 

Processing transfers from step 4002 to step 4004 in which string 3904-C. which is a copy of string 3904, 
is created, resulting in the state shown in Figure 39E. Strings 3904 and 3904-C are contained within frame 
3906 which is part of the execution state of agent 1 50A and which records the dynamic state of operation "store" 
as performed by agent 1 SOB. Processing transfers from step 4004 to step 4006 (Figure 40) where agent 1 SOB 

45 stores string 3904-C. Processing transfers from step 4006 to step 4008 in which agent *50B discards string 
3904, which was popped from stack 3902. Processing transfers from step 4008 to terminal step 40 10 in which 
operation "store" completes successfully. Step 4008 results in the state represented by Figure 39F. Thus, agent 
150A has successfully transferred information to agent 150B. 

In this manner, agent 150A interacts with agent 150B by agent 150A requesting agent 150B to perform 

50 an operation, and agent 150A conveys to agent 150B objects as arguments to or results from operations re- 
quested or performed, respectively. While agent 150B is described as performing an operation at the request 
of agent 150A. it is reiterated here that performance of a feature by an object is, in actuality, performance of 
the feature by an engine in the context of that object defined by that object's internal state and class. The be- 
havior of a particular feature can vary depending on the internal state of the object performing the feature, 

55 where the internal state of the object is defined in part by the object's properties. 

Agent 150B can similarly transfer an object to agent 150A by pushing the object on to stack 3902. e.g., 
after step 4008 and before terminal step 4010. The object is popped from stack 4010 as a result of operation 
"store" by agent 150A. Furthermore, since agent 150B contains a reference to agent 150A, as discussed above 
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with respect to operation "meet", agent 150B is similarly capable of directing agent 150Ato perform an oper- 
ation and of supplying to agent 150A objects as arguments to the operation. 

Portability of the Computer Instruction Set of the Present Invention 

5 

A number of aspects of the present invention permit processes a great deal of mobility and versatility. First, 
the computer instruction set of the present invention is homogeneously implemented in a homogeneous or 
heterogenous network. Second, classes are objects of the computer instruction set so that classes can travel 
throughout the network with mobile processes. And third, the computer instruction set is interpreted. 

10 

Homogeneity of the Computer Instruction Set 

As discussed above, an agent, which includes data and computer instructions, is capable of traveling from 
one computer system to another and of executing on whichever computer system the agent may be found. 
15 Furthermore, the network throughout which agents are capable of traveling can be either homogeneous or 
heterogeneous. In view of the mobility of agents, it is not always possible to determine exactly which computer 
system of the network executes each of the computer instructions forming the procedural portion of an agent. 
It is therefore important that each computer system of the network, throughout which agents can travel, sup- 
ports the same computer instruction set. 

20 

Classes Represented as Objects in the Disclosed Computer Instruction Set 

An agent executing within a first computer system is capable of creating new classes of objects which did 
not previously exist. The agent can then travel to an engine which is executing within a second computer system 
25 and interpretation of the agent, involving processing of members of the newly created class, continues within 
the second computer system. In such a case, the engine executing within the second computer system has 
never before encountered the newly created class or any members of that class. Therefore, classes are made 
objects of the disclosed instruction set so that classes are capable of traveling with agents from one computer 
system to another. 

30 

Class Structure 

Several objects combine to define and represent a class: a class object, an identifier, and a class definition. 
Class objects, identifiers and class definitions are members of the respective classes "Class", "Identifier" and 

35 "Class Definition". Class objects, i.e., members of class "Class", are objects which represent a set of objects 
whose features have the same interface and implementation. The set of objects are the "instances" of the class. 
Class "Class" and class objects are discussed in greater detail below and in Appendix A. 

Identifiers, i.e., members of class "Identifier", are used within an interface object or an implementation 
object to reference a class. It should be noted that identifiers reference other types of objects as well. Interface 

40 objects and implementation objects are discussed below in greater detail. A first identifier referencing a first 
class within a first interface object or implementation object is distinct from identifiers referencing all other 
classes within the first interface object or implementation object. However, a second interface object or im- 
plementation object can use an identifier equivalent to the first identifier to reference a second class. 

An interface object and an implementation object together define a number of features, i.e., operations 

45 and attributes. The distinction between an attribute, in which case an object is directed to provide or alter a 
portion of the object's internal state, and an operation, in which case an object is directed to perform a number 
of computer instructions, serves primarily to aid in conceptualization of the present invention. Conceptually, 
an attribute is a special case of an operation. For example, querying an attribute of an object directs the object 
to perform computer instructions which cause the object to provide information regarding the internal state of 

50 the object. 

It is reiterated here that performance of a feature by an object is, in actuality, performance of the feature 
by an engine in the context of that object defined by that object's internal state and class. The behavior of a 
particular feature can vary depending on the internal state of the object performing the feature, where the in- 
ternal state of the object is defined in part by the object's properties. 
55 A single identifier can simultaneously identify two separate features, each feature defined by a different 

class. For example, operation "add" is defined by class "Number" differently than by class "Dictionary". In se- 
lecting an interface and implementation, the engine carrying out performance of a feature selects the feature 
definition and associated method object appropriate for the class of object performing the feature. In other 
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words, the feature definition is retrieved from the classes of which the responder is a member. Aconcrete class 
defining a feature defines both the feature's interface and the feature's implementation. An abstract class 
which defines a feature defines the feature's interface and can define the feature's implementation. 

The "interface" of a feature defines the arguments consumed in performance of the feature as well as the 

5 result produced, if any. Additionally, the exceptions which can be produced by a feature are defined by the 
feature's interface. The interfaces of the features defined by a class are collectively represented and defined 
by an interface object, i.e., a member of class "Interface", which is property "interface" of a class definition 
object. Class "Interface" is discussed below in more detail. 

A feature's implementation is defined by the feature's "method." A feature's method defines actions to be 

10 taken, i.e. computer instructions to be executed, in performance of the feature. A method object, a member of 
class "Method", is generally a sequence of instructions whose execution constitutes performance of the fea- 
ture. The implementations of the features defined or inherited by a class are collectively represented and de- 
fined by an implementation object, i.e., a member of class "Implementation", which is property "implementa- 
tion" of a class definition object. Class "Implementation" is discussed below in more detail. 

15 Feature definitions are inherited from a class's superclasses. In other words, if a feature is defined for a 

particular class, that feature is also defined for that class's subclasses. However, a subclass is capable of re- 
defining the implementation of the feature, superseding the implementation inherited from the superclass. 
However if the feature is "sealed" by a superclass of the subclass for which the feature is defined, the subclass 
cannot redefine the implementation inherited from the superclass. 

20 The features defined by a class are defined by the class's class definition, a member of class "Class Def- 

inition". The class itself is represented by a class object, a member of class "Class". The class is referenced 
by an identifier, a member of class "Identifier". 

A class is created by first creating a class definition, the structure of which is discussed in Appendix A. 
The class definition is directed to perform operation "makeClasses" to create an associated class object. The 

25 syntax and behavior of operation "makeClasses" is discussed in more detail in Appendix A. The particular form 
and structure of the formed class object is not essential so long as (i) the information contained within the class 
definition object is preserved and (ii) citation 4108 (Figure 41 A), interface object 4110, and implementation 
object 4112 can be derived from the class object. Condition (ii) is necessary for the encoding of a class object 
as described in Appendix B. 

30 The engine carrying out performance of operation "makeClasses" on behalf of class definition 41 00 (Figure 

41A), in one embodiment, forms class object 4102 (Figure 41B) by replicating in class object 4102 the prop- 
erties of class definition 4 1 00. After performance of operation "makeClasses", class definition 41 00 is discard- 
ed. The properties of class definition 4100 are discussed in greater detail below. As the properties of class 
definition 4100 are replicated in class object 4102. class object 4102 contains all of the information contained 
35 in class definition object 4100 and can derive the properties of class definition object 4100. 

In another embodiment, processing efficiencies of compiled computer processes are realized by replicat- 
ing information in citation 4108, interface object 4110 and implementation object 411 2 to form citation structure 
4108C (Figure 41 C), interface structure 4 11 0C and implementation structure 411 2C, respectively, within class 
object 4104. Computer processes which are formed of computer instructions which are compiled, rather than 
■*o interpreted, are generally more efficient, i.e., perform a given task within a fewer number of CPU clock cycles, 
than computer processes whose instructions are interpreted. As discussed above, computer instructions are 
initially in human-intelligible source code. Before a computer instruction can be executed by a computer, the 
instruction must be translated into a computer-intelligible object code or machine code. As interpreted computer 
processes require such translation for each computer instruction executed, and as compiled computer proe- 
ms esses do not require such translation during execution of a compiled computer process, compiled computer 
processes can be substantially more efficient than interpreted computer processes. 

Citation structure 4108C, interface structure 4110C and implementation structure 4112C are objects 
which are analogous to citation 4108, interface object 4110 and implementation object 4112 and which are 
formed of compiled computer instructions such the computer instructions which collectively form the C++ pro- 
50 gramming language. By replicating the structures of citation 4108, interface object 4110, and implementation 
object 4112 (Figure 41A) in class object 4104 (Figure 41C) as citation structure 4108C, interface structure 
4110C, and implementation structure 4112C, respectively, information regarding the class represented by 
class object 41 04 can be retrieved substantially more efficiently than by retrieving the information from citation 
4108. interface object 41 10 and implementation object 4112 of class object 4102 (Figure 41 B). The information 
55 contained within citation structure 4108C (Figure 41C), interface structure 4110C, and implementation struc- 
ture 411 2C is substantially equivalent to the information contained within the corresponding properties of class 
definition 4100 (Figure 41A). 

As the information contained within a class object is substantially equivalent to the information contained 
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within the class definition from which the class object is derived, discussion of the structure of a class definition 
also describes the nature of the information contained within a class object. 

Class Definition Objects 

5 

The features defined by a class are defined in the class definition object which defines the class. The struc- 
ture of class definition object 4100 is shown in Figure 41 A. Class definition object 4100 includes properties 
"citation", "interface" and "implementation". Citation 4108 is property "citation" of class definition object 4100 
and identifies the class defined by class definition object 4100 and further identifies the authority, title and 
10 edition of the class. The structure of a citation is discussed in greater detail below and in Appendix A. 

Interface object 4110 and implementation object 4112 are, respectively, properties "interface" and "imple- 
mentation" of class definition object 4100. Interface object 41 10 defines the interfaces of the features defined 
by class definition object 4100, and implementation object 4112 defines the implementations of the features 
defined by class definition object 4100. 

15 

Interface objects 

The structure of interface object 41 1 0 is shown in Figure 42. The properties of interface object 41 1 0 include 
properties "isAbstract". "classFeatures", "sealedClassFeatures", "instanceFeatures", "sealedlnstanceFea- 
20 tures", "vocabulary" and "superclasses". 

Boolean 4208 is property "isAbstract" of interface object 4110. If boolean 4208 is "true", the class, whose 
interface is interface object 4110, is abstract. The class is concrete otherwise. 

Lexicon 4210 is property "classFeatures" of interface object 4110. Lexicon 4210 is a lexicon of the defi- 
nitions of the "class features" of the class. The class features of a class are the features for which the class 
25 itself, i.e., the class represented by class definition object 4100 (Figure 41A), is the responder. The keys of 
lexicon 4210 (Figure 42), e.g., identifier 421 OK, are identifiers which reference the class features. The values 
of lexicon 4210, e.g., feature definition 4210V, are feature definitions defining the class features. Feature def- 
initions are discussed below in more detail. 

Set 4212 is property "sealedClassFeatures" of interface object 4110. Set 4212 is a set of identifiers, e.g., 
30 identifier 42121, which reference the class features which are sealed. Sealed features are features that sub- 
classes are prevented from adapting. If a feature is not sealed, a subclass of the class represented by class 
definition object 4100 (Figure 41 A) can adapt the feature by redefining the feature's implementation. 

Lexicon 4214 (Figure 42) is property "instanceFeatures" of interface object 41 10. Lexicon 4214 is a lexicon 
of the definitions of the "instance features" of the class. The instance features of a class are features for which 
35 members of the class are the responder. The keys of lexicon 4214 (Figure 42) (no key or value of lexicon 4214 
is shown) are identifiers referencing the instance features, and the values of lexicon 4214 are feature defini- 
tions defining the instance features. 

Set 4216 is property "sealedlnstanceFeatures" of interface object 4110. Set 4216 is a set of identifiers 
(not shown) which reference the instance features which are sealed. 
40 Lexicon 421 8 is property "vocabulary" of interface object 41 1 0. Lexicon 421 8 associates identifiers of user- 

defined classes which are referenced in interface object 4110 with citations of those classes. The keys of lex- 
icon 4218 are identifiers, e.g.. identifier 4218K, and the values of lexicon 4218 are corresponding citations, 
e.g., citation 4218V. Citations are discussed in greater detail below and in Appendix A. Property "vocabulary" 
of interface object 41 10, i.e., lexicon 421 8, is "the vocabulary" of interface object 41 10 and of the class defined 
45 by class definition object 4100 (Figure 41 A). 

List 4220 (Figure 42) is property "superclasses" of interface object 4110. List 4220 is a list of identifiers, 
e.g., identifier 4220I, which reference classes. The classes referenced by identifiers of list 4220 are immediate 
interface superclasses of the class defined by class definition object 4100 (Figure 41 A) . All but the last item 
of list 4220 (Figure 42) must identify mix-in classes, and the last item of list 4220 must identify a flavor. The 
50 importance of the last item of list 4220 identifying a flavor is discussed below in more detail in conjunction 
with the selection of a method object in performing a feature and in conjunction with object initialization. 

Feature Definitions 

55 A feature definition, i.e., a member of class "Feature", is an object which defines the interface of a particular 

feature. The properties of feature definition 4210V (Figure 43) include properties "exceptions" and "isPublic". 
Class "Feature" is abstract; therefore, feature definition 421 0V is a member, not an instance, of class "Feature" 
and is either an operation definition or an attribute definition, both of which are described below and in Appendix 
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A. Set 4302 is property "exceptions" of feature definition 421 0V. Set 4302 is a set of identifiers, e.g., identifier 
4302I, which each reference a class of which exceptions thrown by the feature defined are members. When 
the feature defined by feature definition 4210V throws an exception, the exception is verified to be a member 
of one of the classes referenced by an identifier of set 4302. If the exception is not a member of a class ref- 

5 erenced by an identifier of set 4302. a member of class "Unexpected Exception" is thrown in place of the ex- 
ception. Otherwise, the exception is thrown. 

Boolean 4304 is property "isPublic" of feature definition 4210V. Boolean 4304 indicates whether the fea- 
ture defined by feature definition 4210V is a public feature or a private feature, i.e. whether the access of the 
feature defined is "public" or "private". Each feature has an associated "access" which determines which ob- 

w jects and under what circumstances each feature can be properly requested. The access of each feature of 
this invention is disclosed in Appendices A and B. 

If boolean 4304 is "true", the feature is public. A feature whose access is public can be requested by any 
object. If boolean 4304 is "false", the feature is private. Afeature whose access is private can only be requested 
by the responder, i.e.. an object can only request the feature of itself. System features, i.e., features whose 

15 access is "system", are all predefined and therefore are not defined by feature definitions. Predefined features 
are implemented within an engine and therefore are not represented by objects such as feature definitions. 
One implementation of an engine of one embodiment of the present invention, which implements the disclosed 
predefined features, is disclosed in the software of Appendix G which is incorc ated herein in its entirety by 
reference. 

20 

Attribute Definitions 

A feature definition that defines an attribute is an attribute definition, i.e., a member of class "Attribute". 
Therefore, class "Attribute" is a subclass of class "Feature". As an attribute definition is a feature definition, 
25 an attribute definition inherits the properties defined or inherited by class "Feature" as described above. In 
addition, attribute definition 4400 (Figure 44) includes properties "constraint" and "isSet". 

Constraint 4402 is property "constraint" of attribute definition 4400. Constraint 4402 constrains objects 
representing the attribute defined by attribute definition 4400. As discussed below in greater detail, a constraint 
places restrictions on an object and can restrict (i) the class of which the object is a member, (ii) whether the 
30 object must be an instance of the class, (iii) whether the object can be a nil and (iv) how the object is passed 
between a feature's requester and responder. 

Boolean 4404 is property "isSet" of attribute definition 4400. Boolean 4404 indicates whether the attribute 
defined by attribute definition 4400 can be set as well as queried. If boolean 4404 is "true", attribute definition 
4400 defines an attribute which can be set. Otherwise, the attribute defined by attribute definition 4400 can 
35 only be queried. 

Operation Definitions 

As discussed above, a feature is either an attribute or an operation. Therefore, a second subclass of class 
40 "Feature" is class "Operation". An operation definition, i.e., a member of class "Operation", defines the inter- 
face of an operation. 

Figure 45 shows the structure of operation definition 4500. As an operation definition is a feature definition, 
operation definition 4500 includes the properties defined or inherited by class "Feature" as described above. 
In addition, operation definition includes properties "arguments" and "result". 

45 List 4502 is property "arguments" of operation definition 4500. Property "arguments" of an operation def- 

inition is optional, i.e.. property "arguments" of an operation definition can be a nil rather than a list. If property 
"arguments" is a nil, the operation defined by operation definition 4500 consumes a variable number of argu- 
ments. The performance of an operation whose arguments are variable in number is described in Appendix 
A. Conversely, if property "arguments" is list 4502. the number of arguments consumed by the operation de- 

50 fined by operation definition 4500 consumes a fixed number of arguments, the number being equal to the 
length of list 4502. If property "arguments" is an empty list, the operation consumes no arguments. The items 
of list 4502, e.g., constraint 4502I, are constraints which constrain the arguments of the operation defined by 
operation definition 4500. As discussed below with respect to Figure 46, a constraint constrains an object's 
class and passage. 

55 Constraint 4504 is property "result" of operation definition 4500. Constraint 4504 constrains the result of 

the operation defined by operation definition 4500. Property "result" of an operation definition is also optional. 
If property "result" is a nil rather than constraint 4504, then the operation defined by operation definition 4500 
produces no result. 
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Constraints 

As discussed above, a constraint restricts the class and passage of an object. The structure of constraint 
4402 is shown in Figure 46. The properties of constraint 4402 include properties "classld", "ofClass". "isln- 
5 stance", "isOptional", and "passage". 

Properties "ofClass" and "classld" are alternative ways for specifying the class of which the constrained 
object must be a member. Class object 4602 is property "ofClass" of constraint 4402. Class object 4602 rep- 
resents the class of which an object upon which constraint 4402 is imposed must be a member. Property "of- 
Class" is optional and, therefore, can be a nil. If property "ofClass" is nil, the class of which the object must 
10 be a member is referenced by identifier 4610 which is property "classld" of constraint 4402. 

Property "ofClass" is a class object and therefore can only be a class which exists at the time constraint 
4402 is created. However, requiring that a property of a constraint is a class which exists prevents users of 
the present invention from defining multiple interdependent classes. For example, a constraint in a feature def- 
inition of a first class can refer to a second class and a second constraint in a second feature definition in the 
15 second class can refer to the first class. Providing property "classld" of constraint 4402 as an alternative to 
property "ofClass" enables users to define multiple interdependent classes simultaneously. 

Boolean 4604 is property "islnstance" of constraint 4402. Boolean 4604 indicates whether an object upon 
which constraint 4402 is imposed must be an instance of the class represented by class object 4602. If boolean 
4604 is "true", the constrained object must be an instance of the class. Otherwise, the constrained object's 
20 membership in the class is sufficient to satisfy constraint 4402. 

Boolean 4606 is property "isOptional" of constraint 4402. Boolean 4606 indicates whether a nil object sat- 
isfies constraint 4402, properties "ofClass" and "classld" notwithstanding. If boolean 4606 is "true", a nil object 
satisfies constraint 4402. As illustrated in numerous examples herein, a nil object can be placed on a stack in 
lieu of an omitted optional argument or result of a feature. 
25 Identifier 4610 is property "passage" of constraint 4402. Identifier 4610 indicates in what manner an object 

on which constraint 4402 is imposed is passed as a parameter, i.e., as an argument or result. Identifier 4610 
has four possible values: "byRef", "byLin protected Ref", "byProtectedRef'and "byCopy". Setting identifier 4610 
to a value other than one of these four throws an exception that is a member of class "Passage Invalid". 

In passing a reference to an argument between the requestor of a feature and the responderof the feature, 
30 an engine takes a source reference to the argument from the requestor and provides a destination reference 
to the responder. In passing a reference to a result, the source reference is taken from the responder and a 
destination reference is provided to the requestor. 

If the parameter is passed "byRef. the source reference and the destination reference are the same. If 
the parameter is passed "byUnprotectedRef, an exception of class "Reference Protected" is thrown if the 
35 source reference is a protected reference; otherwise, the destination reference is the source reference. If the 
parameter is passed "byProtectedRef", the destination reference is a protected reference to the object refer- 
enced by the source reference. If the parameter is passed "byCopy", the destination reference is an unprotected 
reference to a copy of the object referenced by the source reference. Passage of parameters is discussed fur- 
ther in Appendix A. 

40 Thus, constraint 4402 (Figure 44) restricts the class and passage of an object. 

Implementation Object 

As discussed above, implementation object 4112 (Figure 41 A) defines the class implementation of the 
45 class defined by class definition object 4100. A class implementation defines the following: (i) zero or more 
properties of the members of the class defined; (ii) the respective implementations of the various class features 
and (iii) instance features defined by a class; (iv) methods for setting attributes defined for the class; (v) meth- 
ods for converting objects from the class defined to a second class; (vi) methods for converting objects from 
a second class to the class defined; (vii) definitions of identifiers used to define classes; and (viii) the imple- 
50 mentation superclasses of the class defined. 

List 4702 (Figure 47) is property "properties" of implementation object 4112. List 4702 defines the prop- 
erties that implementation object 4112 implements. The items of lexicon 4702, e.g., identifier 4702I, are iden- 
tifiers of the properties defined by implementation object 4702. 

Lexicon 4704 (Figure 47) is property "classMethods" of implementation object 411 2. Lexicon 4704 provides 
55 methods for the class features of the class represented by class definition object 41 00 (Figure 41 A). The keys 
of lexicon 4704, e.g., identifier 4704K (Figure 47), are identifiers of the class features, and the values of lexicon 
4704, e.g., method object 4704V, are method objects which define the implementation of the class features. 
A method object, i.e.. a member of class "Method", is an object which defines the method of a feature. 
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The method of a feature is the particular series of steps taken by an engine, and therefore the computer system 
within which the engine is executing, in carrying out performance of the feature. 

A method is defined in terms of the disclosed instruction set as the instruction set is amended by any user- 
defined classes or features. Method objects are discussed in greater detail below and in Appendix A. 
5 Lexicon 4706 is property "instanceMethods" of implementation object 41 1 2. Lexicon 4706 associates iden- 

tifiers of instance features with corresponding method objects, which in turn define the implementation of the 
instance features. The structure of lexicon 4706 is similar to the structure of lexicon 4704 and that discussion 
is incorporated herein by reference. 

Lexicon 4707 is property "setMethods" of implementation object 411 2. Lexicon 4707 associates identifiers, 
10 which identify respective attributes, with method objects. Each of the method objects of lexicon 4707 imple- 
ments the attribute of the corresponding identifier when executed in the presence of a "set" modifier. In other 
words, each method object of lexicon 4707 defines the implementation of the setting of a corresponding at- 
tribute. The execution of an attribute in the presence of a "set" modifier is discussed in Appendix A. 

Lexicon 4708 is property "fromMethods" of implementation object 4112. Lexicon 4708 associates identi- 
15 f iers with method objects. Each identifier references a class and is associated with a method object which pro- 
vides the implementation of the conversion from the referenced class to the class defined by class definition 
object 4100 (Figure 41A). i.e., the class whose implementation is implementation object 4112 (Figure 47). . 

Lexicon 4710 is property "toMethods" of implementation object 411 2. Lexicon 4710 associates identifiers 
with method objects. Each identifier references a class and is associated with a method object which provides 
20 the implementation of the conversion to the referenced class from the class defined by class definition object 
4100 (Figure 41 A), i.e., the class whose implementation is implementation object 41 12 (Figure 47), The struc- 
ture of lexicons 4707, 4708 and 4710 is similar to the structure of lexicon 4704 and that discussion is incor- 
porated herein by reference. 

Lexicon 471 2 is property "vocabulary" of implementation object 411 2. Lexicon 471 2 defines the identifiers 
25 used by implementation object 4112 to identify classes. The keys of lexicon 4712, e.g., identifier 4712K, are 
identifiers used within implementation object 41 12 to identify specific user-defined classes. The values of lex- 
icon 4712, e.g., citation 471 2V, are corresponding citations which identify the class identified by the associated 
identifier. Lexicon 471 2 provides a translation between an identifier used to identify a user-defined class within 
implementation object 4112 and a citation used to identify the class throughout the network. Citations are dis- 
30 cussed in greater detail below and in Appendix A. . 

List 4714 is property "superclasses" of implementation object 4112. The items of list 4714, e.g., identifier 
47141, are identifiers which identify the implementation superclasses of the class defined by class definition 
4100 (Figure 41 A). List 4714 (Figure 47), i.e. property "superclasses" of implementation object 4112, can con- 
tain identifiers of classes which are not items of list 4220, i.e. property "superclasses" of interface object 4110. 
35 For example, a first class may benefit from the ability to use features of a second class in implementing fea- 
tures of the first class. However, in designing such a class, it is not always preferred that the features of the 
second class are themselves inherited by the first class. In such cases, the second class is made an imple- 
mentation superclass but not an interface superclass of the first class. 

Thus, implementation object 4112 defines, for the class defined by class definition object 4100 (Figure 
40 41 A), (a) properties of the members of the class defined, (b) the class and instance feature methods, (c) meth- 
ods for setting attributes, (d) methods for conversion to and from the class defined, (e) identifiers used to iden- 
tify classes, and (f) implementation superclasses. 

Method Objects 

45 

As discussed above, a method object defines the computer instructions executed in performance of a fea- 
ture or a conversion. Figure 48 shows the structure of method object 4800. Properties of method object 4800 
include properties "procedure" and "variables". Procedure 4802 is property "procedure" of method object 4800. 
Performance of procedure 4802 constitutes performance of the feature or a conversion implemented by meth- 

50 od object 4800. Procedures are discussed in more detail below. 

List 4804 is property "variables" of method object 4800. List 4804 defines the variables that are used by 
procedure 4802. The items of list 4804. e.g., identifier 4804I, are identifiers which reference the variables de- 
fined for method object 4800. Associated objects which represent the values of the variables of a method are 
stored in a list as property "variables" of a user-defined frame during performance of the method. Frames are 

55 discussed in greater detail below and in Appendix A. 



53 



EP 0 634 719 A2 



Procedure 

The structure of procedure 4802 is shown in Figure 49. 
Procedure 4802 includes list 4902 of objects 4902A-4902E. List 4902 is not a member of class "List", but is 

5 instead an integral part of procedure 4802. In other words, list 4902 is not a property or item of procedure 4802 
and no feature is provided which permits list 4902 to be treated as a member of class "List". In one embodiment 
of the present invention, class "Procedure" is an implementation subclass of class "List" but is not an interface 
subclass of class "List". Therefore, the features that are defined by class "List" are not inherited by class "Pro- 
cedure" but the methods defined by class "List" can be used by a procedure to create and access list 4902. 

w Objects 4902A-4902E are executed objects, i.e., members of mix-in class "Executed". Procedure 4802 is 

performed by executing objects 4902A-4902E sequentially, i.e., in the order of object 4902A, object 4902B, 
object 4902C, object 4902D and object 4902E. During execution of procedure 4802. a predefined frame records 
and maintains the dynamic state of a performance of procedure 4802, including which of objects 4902A-4902E 
is executing. Predefined frames are discussed below and in detail in Appendix B. 

15 

Citation 

A citation is an object which identifies a series of objects each of which is backward- or forward-compatible 
with the others. A citation further identifies a particular object in the series and the process, or the authority 
20 of the process, that created the particular object. As discussed briefly above, classes are cited objects. There- 
fore, citations are used to identify series of classes which are backward- and forward-compatible with one an- 
other. Backward- and forward-compatibility are discussed in greater detail below and in Appendix A. 

It should be noted that objects whose citations identify the objects as forward- or backward compatible 
with one another are not necessarily forward- or backward-compatible. For example, two class definition ob- 
25 jects which are identified by their respective citations as compatible are merely intended to be compatible. 

Citation 5000 (Figure 50) is a member of class "Citation". The properties of citation 5000 include properties 
"title", "majorEdition", "minorEdition" and "author". Property "title" of citation 5000 is identifier 5008. Identifier 
5008 is therefore the title of citation 5000. The title of a citation references the series that the citation repre- 
sents. The title of a citation is interpreted relative to the citation's authority. In other words, two citations of 
30 different authorities can use equivalent titles. The two citations are distinguished from one another by the dif- 
ferent authorities. The authority of a citation is identified by property "author" which is discussed below. 

Properties "majorEdition" and "minorEdition" are integers 5004 and 5006, respectively. Integers 5004 and 
5006 are therefore the major and minor editions, respectively, of citation 5000. The relation between two ob- 
jects in a series is determined by the relative major and minor editions of the objects. For example, objects 
35 5102 and 5104 (Figure 51) are cited by citations 5106 and 5108, respectively. Integers 5110 and 5112 represent 
the major and minor editions, respectively, of citation 5106. Integers 5114 and 5116 represent the major and 
minor editions, respectively, of citation 5108. 

If integer 5110, the major edition of citation 5106, is greater than integer 5114, the major edition of citation 
5108. then object 5102 was created subsequent to the creation of object 5104 and is backward-compatible 
40 with object 5104. If object 5102 is backward-compatible with object 5104, object 5104 is forward-compatible 
with object 5102. Conversely, if integer 5110 is less than integer 5114, object 5104 was created subsequent 
to the creation of object 5102 and is backward-compatible with object 5102. 

If integers 5110 and 5114 are equal, the relative values of integers 5112 ad 5116. respectively representing 
the minor editions of objects 5102 and 5104, determine the relation between objects 5102 and 5104. For ex- 
45 ample, if integer 51 1 2 is greater than integer 51 1 6, object 51 02 was created subsequent to the creation of object 
5104 and is backward-compatible with object 5104. Conversely, if integer 51 12 is less than integer 51 16, object 
5104 was created subsequent to the creation of object 5102 and is backward-compatible with object 5102. 

Property "author" is telename 5002 (Figure 50). Telename 5002 is therefore the author of citation 5000. 
Telename 5002 is the name of the process creating the object identified by citation 5000. All objects of a single 
so series are created by processes of a single authority. 

While a more precise definition of "forward-" and "backward-compatibility" is given in Appendix A, the fol- 
lowing example illustrates the meaning and utility of such concepts. As defined in Appendix A, a member of 
class "Integer", i.e., an integer, can perform a numberof arithmetic operations, including "add", "subtract", "mul- 
tiply" and "divide". Property "citation" of class "Integer" is a first citation identifying class "Integer". In imple- 
55 menting the set of computer instructions described herein and in defining new classes and new features in 
using the set of computer instructions described herein, a plethora of features are designed in reliance of mem- 
bers of class "Integer" comporting with the description of class "Integer" as described in Appendix A. 

Suppose in a subsequent version of the set of computer instructions described herein that a second class 
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"Integer" is defined to provide an operation "randomize" to generate random numbers. The former class "In- 
teger" is called the first class "Integer". Property "citation" of the second class "Integer" is a second citation. 
Suppose further that there are no other differences between the first class "Integer" and the second class "In- 
teger" and that any feature requested of a member of the first class "Integer" is satisfied by a member of the 
5 second class "Integer". Thus, the features which are designed in reliance of integers comporting with the de- 
scription of the first class "Integer", function properly given integers of the second class "Integer". The second 
class "Integer" is therefore backward-compatible with the first class "Integer". Conversely, the first class "In- 
teger" is forward-compatible with the second class "Integer". 

Property "title" of both the first and the second citations is equal and references either class "Integer". How- 
to ever, the major and minor editions of the first and second citations reflect the forward- and backward-compa- 
tibility relation between the first and second classes "Integer". Permitting backward- and forward-compatible 
objects to co-exist within the network permits objects created by earlier versions of the set of computer in- 
structions described herein to travel to and operate within engines implementing a later version of the set of 
computer instructions described herein. It is clear from the foregoing that a class is both forward- and back- 
15 ward-compatible with itself. While the illustrative example above demonstrates forward- and backward-com- 
patibility in the context of a predefined class, user-defined classes are typically changed more frequently than 
predefined classes. Therefore, providing for forward- and backward-compatibility among classes is particularly 
important in the context of user-defined classes. 

Thus, classes are made part of the disclosed instruction set and are therefore portable and can travel with 
20 an agent from a first computer system to a second computer system. 

Interpreted Instruction Set 

As discussed above, three aspects of the present invention make computer processes particularly mobile 

25 and general. The first is that the computer instruction set of the present invention is implemented homogene- 
ously in a homogeneous or heterogeneous network. Secondly, classes are objects of the disclosed computer 
instruction set so that the instruction set is both extensible and mobile. That is, classes, which are not defined 
on remote computer systems, are transported with mobile computer processes to such remote computer sys- 
tems. The following discussion concerns the third aspect making the computer instruction set particularly gen- 

30 eral and mobile; the computer instructions of the disclosed computer instruction set are interpreted. 

Most computer processes are first written in a human-readable source code which is then compiled into 
object code and linked into machine code, which is entirely unintelligible to human beings. The primary advan- 
tage of translating the source code into machine code is that the translation need occur only once as the ma- 
chine code can be executed by a computer system's CPU any number of times without recompilation of the 

35 source code. However, two computer systems of a heterogeneous network can have incompatible CPUs which 
do not both execute identical machine code instructions. It is therefore preferred that agents, traveling from 
a first computer system to a second computer system, be represented in a standardized instruction set that is 
not specific to either the first or the second computer system. 

Since the advantages of one-time compilation of source code are eliminated by the heterogeneity of the 

40 network, the disclosed computer instruction set is interpreted. The term "interpreted" is used herein as it is 
understood in the art; a computer instruction in a series of computer instructions is read, translated into ma- 
chine code, and executed by an engine before the next computer instruction in the series is read. 

Interpreting, ratherthan compiling, instructions of the disclosed instruction set provides greater generality. 
A first agent can travel from a first computer system to a second computer system and meet with a second 

45 agent there which gives to the first agent a procedure. The first agent can then perform the procedure which 
the first agent was not originally designed to perform. 

The following discusses the interpretation of the disclosed computer instructions. The discussion focuses 
on procedures and execution of items of procedures, the items being individual computer instructions. 

50 Execution of a Procedure 

A procedure is performed by issuing an instruction requesting that the procedure perform operation "do". 
Other operations which cause performance of a procedure are discussed below and in Appendix A. Perfor- 
mance of operation "do" as defined for class "Procedure" is shown by logic flow diagram 5200 (Figure 52A) 
55 and is represented by a predefined frame 5250 (Figure 52B). Predefined frame 5250 includes properties "pos- 
ition" and "procedure", which are, respectively, integer 5252 and procedure 4802. Predefined frames are dis- 
cussed in greater detail in Appendix B. Predefined frame 5250 records the dynamic state of operation "do" as 
performed by procedure 4802 (Figure 49). 
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In step 5202 (Figure 52A), integer 5252 is set to a value of one. Integer 5252 identifies the position, within 
procedure 4802. of the item whose execution was most recently begun. Processing transfers from step 5202 
(Figure 52A) to end of procedure test step 5204 in which integer 5252 (Figure 52B) is compared to the length 
of procedure 4802. If integer 5252 is less than or equal to the length of procedure 4802, processing transfers 
5 from end of procedure test step 5204 (Figure 52A) to step 5208. In step 5208, the item, whose position within 
procedure 4802 (Figure 52B) is integer 5252 is performed. The performance of an executed object is discussed 
below in more detail and in Appendix A. 

Once an item of procedure 4802 is performed, processing transfers from step 5208 (Figure 52A) to ex- 
ception test step 5210. In exception test step 5210, the engine interpreting procedure 4802 (Figure 52B) de- 
w termines whether performance of the item succeeded or threw an exception. If an exception is thrown, proc- 
essing transfers from exception test step 5210 (Figure 52A) to terminal step 5212 in which operation "do" fails 
and the performance of procedure 4802 (Figure 52B) completes. 

If no exception is thrown by performance of the item at the position within procedure 4802 indicated by 
integer 5252 in step 5208 (Figure 52A), processing transfers from exception test step 5210 to step 5214 in 
15 which integer 5252 (Figure 52B) is incremented. Processing transfers from step 5214 (Figure 52A) to end of 
procedure test step 5204 in which property "position" of predefined frame 5250 (Figure 52B), i.e. , integer 5252, 
is compared to the length of responding procedure 4802 as described above. 

If integer 5252 (Figure 52B) is greater than the length of procedure 4802, processing transfers from end 
of procedure test step 5204 (Figure 52A) to terminal step 5216 in which operation "do" completes successfully. 
20 Thus, performance of operation "do" by procedure 4802 (Figures 49 and 52B) results in the execution of 

each of the items of procedure 4802 in the order described above. 

Execution Model 

25 As discussed above, the primary function of an engine, e.g., engine 132B (Figure 15A), is the performance 

of procedures, i.e., the execution of the items of procedures. The execution model of the disclosed embodiment 
of the present invention is the process by which items of procedures are executed. Discussion of the execution 
model of the disclosed embodiment is divided into six sections. First, the structure and organization of frames 
is discussed. Frames are objects which record the dynamic state of a method implementing a feature or a con- 

30 version. Second, the execution of identifiers is discussed. The execution of an identifier which references a 
feature causes the feature referenced to be performed. Third, the process by which a method object imple- 
menting a feature or a conversion is selected from the class hierarchy is discussed. The structure of class 
objects, from which a method object is retrieved, is described above. Fourth, the escalation of a feature is dis- 
cussed. Fifth, the execution of modifiers is discussed. And sixth, the execution of selectors is discussed. 

35 

Frames 

A frame is an object which records the dynamic state of a method implementing a feature or a conversion 
during the feature's or conversion's execution. The execution state of a process, i.e.. an agent or a place, is 

40 recorded in one or more frames. For example, the execution state of process 5300 (Figure 53) is shown. When 
a process is created, the process is asked to perform operation "live". Created within process 5300 is a property 
"frames" which is stack 5302 which in turn represents the execution thread of process 5300. Stack 5302 con- 
tains the frames which collectively form the execution state of process 5300. When process 5300 is first asked 
to perform operation "live", the sole item on stack 5302 is user-defined frame 5304 which records the dynamic 

45 state of operation "live". 

Since predefined classes "Process", "Agent" and "Place" are abstract, processes of the disclosed embodi- 
ment of the present invention are instances of user defined classes. Predefined abstract classes "Process", 
"Agent" and "Place" do not define an implementation for operation "live". Therefore, frame 5304 recording the 
dynamic state of the method of operation "live" is necessarily a user-defined frame. A user-defined frame is 

so a frame which records the dynamic state of an operation with a user-defined implementation during execution 
of the operation. The structure of user-defined frame 5304 is shown in Figure 54. 

The properties of user-defined frame 5304 (Figure 54) include properties "class", "responder", "proce- 
dure", "position", "stack" and "variables". Class object 5402 is property "class" of user-defined frame 5304, 
which is a property inherited from superclass "Object". Class object 5402 represents the class of which user- 

55 defined frame 5304 is an instance and therefore represents class "User-defined Frame" or a subclass thereof. 

Objec :-04 is property "responder 1 * of user-defined frame 5304. Object 5404 is the responder of the fea- 
ture or conversion whose dynamic state user-defined frame 5304 records. In the context of Figure 53, object 
5404 is process 5300 as process 5300 is the responder of operation "live". 
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Procedure 5406 (Figure 54) is property "procedure" of user-defined frame 5304, which is a property in- 
herited from superclass "Procedure Frame". Procedure 5406 is property "procedure" of the method object 
whose dynamic state user-defined frame 5304 records. For example, if user-defined frame 5304 records the 
dynamic state of method object 4800 (Figure 48). procedures 4802 and 5406 are the same procedure. 

5 Integer 5408 is property "position" of user-defined frame 5304 inherited from superclass "Procedure 

Frame". Integer 5408 identifies the position within procedure 5406 of the item of procedure 5406 which is cur- 
rently being executed. For example, if the second item of procedure 5406 is the item of procedure 5406 whose 
execution has begun and has not yet finished, the value of integer 5408 is two. 

User-defined frame 5304 includes two additional properties, namely, properties "stack" and "variables". 

w Stack 541 0 is property "stack" of user-defined frame 5304 and is the stack of user-defined frame 5304. At the 
beginning of execution of procedure 5406, stack 5410 contains the arguments consumed by performance of 
the feature or conversion whose dynamic state is recorded by user-defined frame 5304. After execution of pro- 
cedure 5406, stack 5410 contains the result, if any, produced by performance of the feature or conversion. 
List 541 2 is property "variables" of user-defined frame 5304. The items of list 5412. e.g. object 541 21, are 

15 the variables of the frame. Variables record the dynamic state of user-defined frame 5304 as procedure 5406 
is performed. Variables which are items of list 5412 (Figure 54) are referenced by like-positioned items of prop- 
erty "variables" of the method object whose dynamic state is recorded by user-defined frame 5304. For ex- 
ample, if user-defined frame 5304 records the dynamic state of method object4800 (Figure 48), identifier 4804I 
which is at position one within list 4804 references object 54121 (Figure 54) which is at position one within list 

20 5412. 

Thus, user-defined frame 5304 records the dynamic state of a user-defined feature or conversion by re- 
cording (i) the responder of the feature or conversion, (ii) the procedure implementing the feature or conversion, 
(iii) the position within the procedure of the currently executing instruction, (iv) the stack containing the argu- 
ments or result of the feature or conversion and (v) the variables which record the dynamic state of user-defined 
25 frame 5304. 

Execution of Executed Objects 

As discussed above, the performance of a procedure is the sequential execution of the items of the pro- 
30 cedure. In general, the execution of an executed object, i.e., an object which inherits from mix-in class "Exe- 
cuted", results in a reference to the object being pushed on to the stack, e.g., stack 5410. of the frame repre- 
senting the execution state of the procedure. However, the execution of identifiers, modifiers and selectors 
are exceptions to this general rule. 

35 Identifiers 

Unless executed in the presence of a modifier indicating otherwise, an executed identifier is presumed 
to reference a feature and therefore invokes an operation or queries an attribute. Execution of an identifier 
within a first procedure causes the feature referenced by the identifier to be performed, thereby causing the 

40 performance of a second procedure. The second procedure is the procedure of the method object which im- 
plements the operation or attribute referenced by the identifier. The execution of an identifier which references 
a feature is shown by logic flow diagram 5500 (Figure 55). 

Logic flow diagram 5500 is discussed in the context of Figures 56A-56C. Stack 5302 (Figure 56A) is the 
execution thread, i.e.. property "frames", of process 5300. User-defined frame 5304 is the current frame. The 

45 current frame is the frame containing the procedure, i.e., procedure 5406, whose items are currently being 
executed by an engine. In other words, the next executed object, which an engine executes in the interpretation 
of process 5300, is retrieved from the procedure of user-defined frame 5304. 

Procedure 5406 is property "procedure" of user-defined frame 5304. Integer 5408 is property "position" 
of user-defined frame 5304 and indicates the position within procedure 5406 of the item whose execution was 

50 most recently begun by the engine processing process 5300. 

The execution of an identifier occurs when the item of procedure 5406 at the position indicated by integer 
5408 is an identifier. In this example, the identifier references an operation. The operation referenced by the 
identifier is sometimes called "the subject operation" in the context of Figures 56A-56C and 55. The execution 
of the identifier is shown by logic flow diagram 5500 (Figure 55). 

55 The requester's stack, i.e. stack 541 0, is produced by querying attribute "stack" of user-defined frame 5304 

in step 5502. Since performance of procedure 5405 (Figure 56A) of user-defined frame 5304 is requesting 
execution of the identifier at the position within procedure 5406 indicated by integer 5408, property "responder" 
of user-defined frame 5304, which is the current frame, is the requester of the operation referenced by the 
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identifier. In the context of Figure 56A, the responder is process 5300. Stack 5410 is therefore the "requester's 
stack". 

Processing transfers from step 5502 (Figure 55) to a stack empty test step 5504. At the time the identifier 
is executed, the object at the top of stack 5410 is the responder of the subject operation. In stack empty test 

5 step 5504, the engine interpreting process 5300 determines whether stack 5410 is empty. If stack 5410 is de- 
termined to be empty, processing transfers from stack empty test step 5504 to terminal step 5506 in which an 
exception of the class "Responder Missing" is thrown and the subject operation fails. Otherwise, if stack 5410 
is not empty, processing transfers from stack empty test to step 5508 in which the object (not shown) at the 
top of stack 5410 is popped from stack 5410. The object popped from stack 5410 is the intended responder 

w of the subject operation of the executing identifier and is sometimes referred to as "the responding object" in 
the context of Figures 56A-56C and 55. 

It should be noted that the subject operation is user-defined and therefore represented by a user-defined 
frame. Features which are predefined are represented directly in an engine. In other words, the instructions 
which form a predefined operation are included in the instructions which form the computer process that is an 

15 engine. If the executed identifier references a predefined operation, the instructions which define the operation 
within the engine are located and performed. One implementation of an engine of one embodiment of the pres- 
ent invention, including instructions which define the predefined operations described herein and in Appendix 
A, is disclosed in the software of Appendix G which is incorporated herein in its entirety by reference. 

Processing transfers from 5508 to step 5510. In step 5510, the operation definition defining the subject 

20 operation is retrieved. The selection of the operation definition and the associated method object is discussed 
below in detail. Processing transfers from step 5510 to access test step 5512. In access test step 5512, the 
access of the subject operation is verified. Property "isPublic", e.g., boolean 4404 (Figure 44), is retrieved from 
the operation definition. If the access of the subject operation is not "public", i.e., if property "isPublic" is "false", 
and the responding object is not property "responder" (not shown) of user-defined frame 5304, processing 

25 transfers from access test step 5512 to terminal step 5514. 

In terminal step 5514. an exception of class "Feature Unavailable" is thrown and the subject operation fails. 
Otherwise, if property "isPublic" is "true" or the responding object is property "responder" of user-defined 
frame 5304, the access of the subject operation is acceptable and processing transfers from access test step 
5512 to number of arguments test step 5516. 

30 In number of arguments test step 5516, property "arguments" of the operation definition is produced by 

querying attribute "arguments" of the operation definition. The number of items in the list of property "argu- 
ments" is compared to the number of objects on stack 5410. If property "arguments" defines a number of ar- 
guments that is greater than the number of objects present on stack 5410, processing transfers from number 
of arguments test step 5516 to terminal step 551 8. In terminal step 5518, an exception of class "Argument Miss- 

35 ing" is thrown, causing the subject operation to fail. 

It should be noted that any exception thrown by execution of the identifier which references the subject 
operation, e.g., in either terminal step 5506 or terminal step 5514, causes the subject operation to fail, throwing 
the same exception. 

If stack 5410 contains at least as many objects as there are arguments as indicated by property "argu- 

40 ments" of the operation definition retrieved in step 5510, processing transfers from number of arguments test 
step 5516 to classes of arguments test step 5520. In classes of arguments test step 5520, the engine inter- 
preting process 5300 determines whether each object on stack 5410 in the position of an argument satisfies 
the corresponding constraint within the list that is property "arguments" of the operation definition retrieved 
in step 5510. For example, constraint 4502I of list 4502 (Figure 45), which is property "arguments" of operation 

45 definition 4500. corresponds to the object at the top of stack 5410. The structure of a constraint is discussed 
in greater detail above and in Appendix A. 

As discussed above in greater detail, a constraint restricts an object by specifying (i) a class of which the 
object must be a member, (ii) whether the object must also be an instance of the class specified, and (iii) wheth- 
er a nil satisfies the constraint irrespective of the class specified. Each object on stack 5410 which corresponds 

50 to a constraint is examined to determine whether the object satisfies the constraint in classes of arguments 
test step 5520. If any of the objects on stack 5410 does not satisfy the corresponding constraint of property 
"arguments" of the operation definition, processing transfers from classes of arguments test step 5520 to ter- 
minal step 5522 in which an exception of class "Argument Invalid" is thrown. 

Conversely, if each of the objects on stack 541 0 satisfies the corresponding constraint, processing trans- 

55 fers from class of arguments test step 5520 to step 5524. In step 5524, the method object defining the imple- 
mentation of the subject operation in the context of the responding object is selected. The method object is 
selected from the classes of which the responding object is a member as discussed in greater detail below. 
Processing transfers from step 5524 to step 5526 in which a new user-defined frame 5602 (Figure 56B) 
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is created. Responding object 5604 is made property "responder" of new user-defined frame 5602. Property 
"procedure" of the method object selected in step 5524 is procedure 5606 and is made property "procedure" 
of new user-defined frame 5602. Property "position" of user-defined frame 5602 is initialized to be an integer 
5608 whose value is zero. And property "stack" is initialized to an empty stack 5610. 

5 Once new user-defined frame 5602 is created, processing transfers from step 5526 to step 5528 in which 

objects are moved from stack 5410 of user-defined frame 5304 to stack 5610 of user-defined frame 5602. 
Objects are moved from stack 5410 to stack 5610 such that the order of objects is preserved. In other words, 
the topmost argument on stack 5410 is at the top of stack 5610, and the bottommost argument on stack 5410 
is at the bottom of stack 5610. Each object is moved according to property "passage" of the corresponding 

w constraint of property "arguments" of the retrieved operation definition. 

If property "passage" is "byRef, the reference to the object is popped from stack 5410 and is pushed on 
to stack 5610. Thus, procedure 5606 of new user-defined frame 5602 has the same access to the argument 
as does procedure 5406 of requesting user-defined frame 5304. 

If property "passage" is "byProtectedRef, the reference to the object is popped from stack 5410, is made 

is a protected reference, and is pushed on to stack 5610. Thus, procedure 5606 of new user-defined frame 5602 
cannot alter the argument and the argument is therefore "readonly". 

If property "passage" is "byUnprotectedRef", whether the reference to the argument on stack 5410 of re- 
questing user-defined frame 5304 is protected is determined. Such a determination is made by querying at- 
tribute "isProtected" which is described more completely in Appendix A. If the reference is protected, an ex- 

20 ception of class "Reference Protected" is thrown. Otherwise, the reference is popped from stack 5410 and is 
pushed on to stack 5610. Thus, procedure 5606 of new user-defined frame 5602 is provided access to alter 
the argument passed by unprotected reference. 

If property "passage" is "byCopy", a copy is made of the object found on stack 5410 and an unprotected 
reference to the copy is pushed on to stack 5610 of new user-defined frame 5602. Thus, procedure 5606 is 

25 given unrestricted access to a c;"oy of the argument, which is passed by copy, but has no access to the argu- 
ment itself. 

Thus, new user-defined frame 5602 is complete and represents the dynamic state of the subject operation 
immediately preceding performance of the subject operation. Processing transfers from step 5528 (Figure 55) 
to step 5530 in which new user-defined frame 5602 is included in the execution state of process 5300 by being 
30 pushed on to stack 5302 (Figure 56C). Thus, stack 5410 and the method object whose property "procedure" 
is procedure 5406 are no longer the current stack and current method, respectively. Stack 5610 is the current 
stack and the method object whose property "procedure" is procedure 5606 is the current method. Processing 
transfers from step 5530 (Figure 55) to step 5532, In step 5532, procedure 5606 (Figure 56C) of user-def iped 
frame 5602 is performed. 

35 As performance of procedure 5406 executes an identifier which invokes performance of the subject op- 

eration and the creation of user-defined frame 5602. performance of procedure 5606 of user-defined frame 
5602 can execute identifiers which invoke further operations thereby creating further frames which are sub- 
sequently pushed on to stack 5302 and whose procedures are subsequently performed. Thus, the execution 
state of process 5300 is represented by one or more frames on stack 5302, which is property "frames" of proc- 

40 ess 5300 representing a thread of execution. 

After performance of procedure 5606, user-defined frame 5602 represents the dynamic state of the sub- 
ject operation immediately following performance of the operation. Stack 5610 of user-defined frame 5602 con- 
tains the result, if any, produced by performance of the subject operation. Processing transfers from step 5532 
(Figure 55) to step 5534 in which property "result" of the operation definition defining the subject operation is 

45 produced by querying attribute "result" of the operation definition. Processing transfers from step 5534 to result 
test step 5536, in which the membership of property "result" in class "Constraint" is determined. In other words, 
property "result" is verified to be a constraint and not a nil. If property "result" is a constraint and not a nil, the 
subject operation produces a result and processing transfers from result test step 5536 to a stack empty test 
step 5538. 

50 in stack empty test step 5538, the engine interpreting process 5300 (Figure 56C) determines whether an 

object is present on stack 5610. If stack 5610 is empty, processing transfers from stack empty test step 5538 
(Figure 55) to terminal step 5540. In terminal step 5540, an exception of class "Result Missing" is thrown. If 
stack 5610 (Figure 56C) contains an object, processing transfers from stack empty test step 5538 (Figure 55) 
to class of result test step 5542. In class of result test step 5542. the engine interpreting process 5300 (Figure 

55 56C) determines whether the object on stack 5610 satisfies the constraint that is property "result" of the op- 
eration definition. If the object does not satisfy the constraint, processing transfers from class of result test 
step 5542 (Figure 55) to terminal step 5544. In terminal step 5544, an exception of class "Result Invalid" is 
thrown. If the object satisfies the constraint, processing transfers from class of result test step 5542 to step 
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5546. 

In step 5546. the object is moved from stack 5610 (Figure 56C) of user-defined frame 5602 to stack 5410 
of user-defined frame 5304 according to property "passage" of the operation definition as described above. 
Processing transfers from step 5546 (Figure 55B) to step 5548. 

5 If, in result test step 5536, property "result" is nil. processing transfers directly to step 5548. In step 5548, 

new user-defined frame 5602 is popped from stack 5302 (Figure 56B) and discarded (Figure 56A) . Thus, stack 
5410 and the method object whose property "procedure" is procedure 5406 are again the current stack and 
the current method, respectively. Processing transfers from step 5548 (Figure 55B) to step 5550 in which exe- 
cution of procedure 5406 is continued by incrementing integer 5408 and executing the item of procedure 5406 

10 at the position indicated by integer 5408. Thus, execution of an identifier which references an operation causes 
performance of the operation. 

Operation Definition and Method Selection 

15 As discussed above, an operation definition and a method object, which together define the subject op- 

eration, are selected in steps 5510 and 5524, respectively (Figure 55A). The selection of the operation defini- 
tion and method are described in the context of the embodiment of the present invention described above with 
respect to Figure 41B. In that embodiment, class object 4 102 is formed by replicating properties "citation", "in- 
terface" and "implementation" of class definition 4100. The selected operation definition is selected from an 

20 interface object, and the selected method object is selected from an implementation object. The operation def- 
inition and method object are each selected according to logic flow diagram 5700 (Figure 57). 

The operation definition and method object, which are appropriate, depend on the class of which the re- 
sponding object is an instance. The responding object is examined to determine whether the responding object 
is a class object, i.e., is a member of class "Class" in a class test step 5702. If the responding object is a class 

25 object, processing transfers from class test step 5702 to a class lookup step 5704. In class lookup step 5704, 
property "classFeatures" of the responding object and the interface superclasses of the responding object are 
searched as discussed below. The lexicon of class features, i.e., property "classFeatures". is searched for a 
key which matches the identifier of the subject operation, i.e., the executing identifier. Additionally, in class 
lookup step 5704, property "classMethods" of the responding object and the implementation superclasses of 

30 the responding object are searched, as discussed below, for a method object associated with the executing 
identifier. 

Processing transfers from class lookup step 5704 to a test step 5706 in which the engine interpreting the 
current process, e.g., process 5300 (Figure 56A). determines whether an operation definition and a method 
object are found in class lookup step 5704. If an operation definition and a method object defining the subject 

35 operation are found, processing transfers from test step 5706 to terminal step 5708 where the selection process 
terminates. Otherwise, processing transfers from test step 5706 to instance lookup step 5710. Additionally, if 
the responding object is not a class object, i.e., is not a member of class "Class", processing transfers directly 
from class test step 5702 to instance lookup step 5710. 

In instance lookup step 5710, property "instanceFeatures" of the interface object of the class of which the 

*o responding object is an instance and of the interface objects of the interface superclasses of that class are 
searched for a feature definition associated with the executing identifier. Also in instance lookup step 5710, 
property "instanceMethods" of the implementation of the class of which the responding object is an instance 
and of the implementations of the implementation superclasses of that class are searched for a method object 
associated with the executing identifier. The order in which superclasses are searched is discussed below. 

45 It should be noted that if the responding object is a class object, a class method can only implement a 

class feature and an instance method can only implement an instance feature. 

Processing transfers from instance lookup step 5710 to a second test step 5712 in which the engine de- 
termines whether an operation definition and a method object are found in instance lookup step 5710. If an 
operation definition and method object identified by the executing identifier are found, processing transfers 

so from second test step 5712 to terminal step 5716. In terminal step 5716, the selection process terminates suc- 
cessfully. Otherwise, processing transfers from second test step 5712 to terminal step 5714. In terminal step 
5714, an exception of class "Feature Unavailable" is thrown. 

Portions of the predefined hierarchy, which is disclosed in Appendix A which discussion is incorporated 
herein in its entirety by reference, are shown in Figures 58A and 58B to illustrate the order in which various 

55 classes are searched for appropriate operation definitions and method objects. While Figure 58Aand 58B show 
portions of the predefined interface hierarchy, the method by which the implementation hierarchy is searched 
is as described below with respect to the searching of the interface hierarchy. 

Hierarchy graph 5800 (Figure 58A) shows class object 5802 representing class "List". Class "List" inherits 
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from mix-in superclass "Ordered" and flavor superclass "Collection" represented by class objects 5804 and 
5806. respectively. Class "Collection" inherits from superclass "Object" represented by class object 5808. 
Class "Object" inherits from mix-in superclass "Referenced" represented by class object 5810. In Figures 58A 
and 58B, (i) double lines are drawn between flavor classes and subclasses of the flavor classes, (ii) single 
5 solid lines are drawn between mix-in classes and subclasses of the mix-in classes, and (iii) a dashed line is 
drawn between a class and an instance of the class. As discussed above, the last item of property "superclass- 
es" of either an interface object or an implementation object must not identify a mix-in class. The reason for 
this is discussed below. 

Suppose for illustration purposes that the responding object in the context of logic flow diagram 5700 (Fig- 
w ure 57) is class object 5802 (Figure 58A) representing class "List". In class lookup step 5704 (Figure 57), prop- 
erty "classFeatures" of the interface object, which is property "interface" of class object 5802, is searched for 
an association whose key is the executing identifier. If such an association is found, the feature definition as- 
sociated with the identifier is an operation definition which defines the interface of the subject operation and 
is selected and the search for an operation definition concludes. 
15 If, however, no such association is found, the interface object of the first superclass of class "List", namely, 

class "Ordered" is searched in the same mannerfor an appropriate operation definition. If no appropriately iden- 
tified operation definition is found, the superclasses of class "Ordered" are searched in a depth-first walk of 
the interface hierarchy. Since class "Ordered" has no superclasses, the next item of property "superclasses" 
of the interface object of class "List", i.e.. class "Collection", is searched as described above. Since the last 
20 superclass searched is not a mix-in class, every mix-in superclass is searched before the flavor superclass is 
searched. 

Thus, in the manner described above with respect to class "List", the remainder of the class objects of Fig- 
ure 58A are searched in the following order: class object 5808 representing class "Object" and class object 
5810 representing class "Referenced". 

25 The search for an appropriate method object defining the implementation of the subject operation is as 

described above for the search for an appropriate operation definition with two exceptions. First, property 
"classMethods" of the implementation object of a class is searched for an appropriately identified method ob- 
ject. Second, the implementation superclasses, rather than the interface superclasses, of class "List" are 
searched for an appropriately identified method object. 

30 The importance of the single flavor superclass being the last superclass searched is apparent if one con- 

siders the following hypothetical example. Suppose, for example, that class object 5806, which represents fla- 
vor "Collection", and class objects representing superclasses of class "Collection" are searched before search- 
ing class object 5804. which represents mix-in class "Ordered". Suppose further than class object 5808. which 
represents class "Object", defines one or more features which are adapted by class "Ordered", i.e.. whose 

35 methods are supplied by class object 5804. Since class object 5808. in this hypothetical example, will always 
be searched before class object 5804, the method for any feature defined by class object 5808 will always be 
found in class object 5808. It would therefore be impossible for class object 5804 to adapt any feature defined 
by class object 5808. Therefore, the flavor superclass of a flavor is always the last superclass of that flavor 
that is searched for an operation definition or method. 

40 Continuing in the illustrative example in which the responding object in the context of logic flow diagram 

5700 (Figure 57) is class object 5802 (Figures 58A and 58B) representing class "List", hierarchy graph 5850 
(Figure 58B) shows the classes searched in instance lookup step 571 0 (Figure 57). The search for an operation 
definition and method object for an instance feature of class object 5802 (Figure 58B) differs from the search 
for an operation definition and method object for a class feature as described above in two ways. First, property 

45 "instanceFeatures" of the interface object of a class is searched for an appropriately identified operation def- 
inition, and property "instanceMethods" of the implementation object of a class is searched for an appropriately 
identified method object. Second, the classes of which the responding object, i.e., class object 5802, is a mem- 
ber are searched. 

The manner in which the classes are searched is equivalent to that described above and is not repeated 
50 here. The following classes are searched in the following order until an appropriate operation definition and 
method object are found or until all classes which follow have been searched: (i) class object 581 2 representing 
class "Class" of which class object 5802 is an instance: (ii) class object 5816 representing class "Interchanged", 
a mix-in superclass of class "Class"; (iii) class object 581 8 representing class "Unchanged", a mix-in superclass 
of mix-in class "Interchanged" and therefore of class "Class": (iv) class object 5814 representing class "Cited", 
55 a mix-in superclass of class "Class"; (v) class object 5808 representing class "Object", a flavor superclass of 
class "Class"; and (vi) class object 581 0 representing class "Referenced", a mix-in superclass of class "Object", 
If no operation definition or no method object associated with the executing identifier is found in searching 
the classes of Figures 58Aand 58B, the operation is not defined for the responding object and an exception 
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of class "Feature Undefined" is thrown. 

As described above, if the responding object is not a class, class lookup step 5704 (Figure 57) is skipped. 
For example, if the responding object is list 5802A which is an instance of class "List", the classes shown in 
hierarchy graph 5800 (Figure 58A) are searched in instance lookup step 5712 (Figure 57) as described above. 
5 In one embodiment of the present invention, the interface and implementation hierarchies are independent. 

In other words, an interface superclass of a class is not necessarily an implementation superclass of the class, 
and an implementation superclass of a class is not necessarily an interface superclass of the class. An engine 
ensures that no feature definition is without an implementation, in such an embodiment, during performance 
of operation "makeClasses". Operation "makeClasses" fails, throwing an exception of class "Class Exception", 
10 upon the following condition: the class defined is not abstract, and the class defined does not define, or inherit 
from implementation superclasses, a method which implements a defined feature. Thus, a feature defined in 
the interface hierarchy is always implemented by a method found in the implementation hierarchy. 

Thus, an appropriate operation definition and method object for the subject operation are found by search- 
ing the class hierarchy as discussed above or an exception is thrown. 

15 

Escalation 

As discussed above, a class which inherits a feature from a superclass can supersede the implementation 
of the feature by providing a new implementation for the feature. However, the new implementation may need 
20 to use the implementation provided by the superclass. An object is directed to perform a feature as implement- 
ed by a particular one or by any one of the immediate superclasses of the current class by escalating the fea- 
ture. As described more completely in Appendix A. the current class is the class which provides the currently 
executing method. 

A feature is escalated by executing a qualified identifier which references the feature to be escalated or 
25 by executing an "escalate" selector. Aqualif ied identifier includes property "qualifier" which identifies the class 
which is to provide the implementation of the feature. If a feature is escalated by execution of an "escalate" 
selector, any immediate implementation superclass can provide the implementation of the feature. 

It should be noted that no attribute is defined which provides access to property "qualifier" of a qualified 
identifier. Property "qualifier" of a qualified identifier is set when the qualified identifier is created and remains 
30 unaltered until the qualified identifier is destroyed. Escalation of a feature is discussed further in Appendix A. 

Escalation plays a particularly important role in initializing objects. Appendix A includes a description of 
an initialization for each predefined class of the present invention. The initialization of an object is shown by 
logic flow diagram 5900 (Figure 59) which is discussed in the illustrative context of the initialization of a list, 
i.e. an instance of class "List". Operation "initialize" is escalated for each immediate implementation superclass 
35 of class "List". As discussed above, hierarchy diagram 5800 (Figure 58A) represents the interface superclasses 
of class "List". Hierarchy diagram 5800 also accurately represents the implementation superclasses of class 
"List". 

Operation "initialize", as defined by the class of which the new list is an instance, i.e. class "List", is per- 
formed in step 5902. Performance of operation "initialize" consumes zero or more arguments from the current 
•to stack. Processing transfers from step 5902 to step 5904. In step 5904, property "superclasses" of the imple- 
mentation object of class "List" is produced by querying attribute "superclasses" of the implementation object. 
As described above, property "superclasses" of an implementation object is a list of identifiers which reference 
classes. Processing transfers from step 5904 to for each superclass step 5906. 

For each superclass step 5906 and next step 591 0 define a loop in which each superclass of property "su- 
45 perclasses" produced above is processed in an escalate step 5908. Thus, for each superclass, processing 
transfers from for each superclass step 5906 to escalate step 5908. In escalate step 5908, the superclass is 
directed to perform operation "initialize", according to logic flow diagram 5900. Thus, logic flow diagram 5900 
is performed recursively in a depth-first walk of the implementation hierarchy. For example, the first immediate 
superclass, to which "initialize" is escalated in escalate step 5908. (i) performs "initialize" in step 5902, (ii) pro- 
50 duces immediate implementation superclasses of the superclass in step 5904 and (iii) escalates "initialize" to 
each superclass of the superclass in the loop defined by for e.-ch superclass step 5906 and next step 5910. 

Processing transfers from escalate step 5908 through next step 5910 to for each superclass step 5906. 
Thus, initialization is escalated to each immediate implementation superclass in the order found in the list that 
is property "superclasses". Each performance of operation "initialize" by a superclass of class "List" consumes 
55 zero or more arguments from the current stack and escalates the initialization to the immediate implementation 
superclasses of the superclass. 

Once each immediate implementation superclass of class "List" has performed operation "initialize" ac- 
cording to the loop of for each superclass step 5906 and next step 5910, processing transfers from for each 
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superclass step 5906 to terminal step 5912. In terminal step 5912, performance of operation "initialize" as de- 
fined by class "List" completes successfully. Thus, each class of which the new list is a member performs op- 
eration "initialize" in the order in which classes are searched in instance lookup step 5710 (Figure 57) described 
above. 

Execution of Modifiers 

The execution of an identifier is discussed at length above and in Appendix A. However, the presence of 
a modifier or the nature of the identifier can alter the execution of the identifier. For example, according to 
the modifier substitution rules discussed in Appendix A, if the identifier identifies an attribute, operation "ge- 
tAttribute" is performed consuming as the sole argument the executing identifier. The various modifiers and 
the effects on the execution of an identifier are discussed in Appendix A and such discussion is hereby incor- 
porated by reference. 

Execution of Selectors 

A selector is a primitive whose execution causes a special action. While each selector is discussed in Ap- 
pendix A, several selectors are discussed herein. For example, selectors "break", "continue" and "succeed" 
are discussed below in the context of performing procedures. Execution of selector "self pushes on to the cur- 
rent stack a reference to the current object, i.e. the responder of the current method. In the context of Figure 
56C, the current object is object 5604 which is property "responder" of frame 5602, the current stack is stack 
5610 which is property "stack" of frame 5602, and the current method is the method object whose property 
"procedure" is procedure 5606. Execution of selector "process" pushes on to the current stack a reference to 
the current process. In Figure 56C, the current process is process 5300. If the current process is an engine 
place, a nil is pushed on to the current stack. 

Thus, an engine created according to the present invention executes procedures by sequential execution 
of the items of the procedures. Execution of an item of a procedure when that item is an identifier causes exe- 
cution of the feature referenced by the identifier under the circumstances described above. The dynamic state 
of a procedure being performed is recorded in a frame. Dynamic states of methods implementing features 
which are user-defined are recorded in user-defined frames. Afeature definition and a method object defining 
the interface and implementation, respectively, of the feature are selected from the classes of which the re- 
sponding object is a member. Implementations provided by superclasses of the current class are performed 
by escalating the feature. For example, operation "initialize" is recursively escalated such that the method pro- 
vided by each class of which the responder is a member is performed. Modifiers are used to alter the execution 
of an identifier. And selectors provide a simple means by which commonly performed complex actions are 
caused by execution of a single object. These features combine to provide a great degree of functionality and 
generality in the disclosed set of computer instructions. 

Control Constructs 

As discussed above, an agent can apply sophisticated logic to determine to which place or places to travel 
and with which agent or agents to meet. The disclosed instruction set provides a number of instructions which 
provide a large degree of generality enabling the realization of complex and sophisticated logic in procedures 
constructed of the disclosed instruction set The following control constructs which provide such a large degree 
of generality are discussed: (i) resources and resource allocation features provide processes with the ability 
to obtain and maintain shared or exclusive control of a resource during performance of a procedure; (ii) decision 
handling features enable processes to conditionally perform procedures; (iii) exception handling features en- 
able processes to detect and take action upon the throwing of an exception; and (iv) looping features enable 
a procedure to repeatedly perform a procedure to thereby efficiently perform repetitive tasks. 

Resource and Resource Allocation Features 

As discussed above and in Appendix A, an engine processing one or more processes does so concurrently. 
For example, engine 132B (Figure 15E) concurrently processes agents 150Aand 150B. At any point during 
performance of a first procedure by agent 150A carried out by engine 132B, engine 132B can temporarily sus- 
pend performance of the first procedure by agent 150A. Engine 132B is then free to carry out performance 
of a second procedure on behalf of agent 1 SOB. At any point during performance of the second procedure, en- 
gine 1 32B can temporarily suspend performance of the second procedure on behalf of agent 1 50B and resume 
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performance of the first procedure on behalf of agent 150A. In this manner, engine 132B concurrently proc- 
esses agents 150Aand 150B. 

As discussed in Appendix A, an engine carries out performance of most of the predefined features atom- 
ically. A feature is performed atomically if the engine refuses to suspend performance of the feature for the 
5 purpose of processing another process until the feature has completed successfully or failed. When a feature 
is performed atomically, no process but the current process can alter or manipulate resources since no other 
process will be interpreted during performance of the feature. Those predefined features which are not per- 
formed atomically are discussed in Appendix A. 

There is no mechanism for causing a user-defined feature to be performed atomically. Thus, a mechanism 
w is needed to enable a process to obtain shared or exclusive use of a resource during performance of a user- 
defined feature or a predefined feature which is not performed atomically. A user is able to configure a process 
to obtain shared or exclusive use of a resource by use of operation "use" which is defined by class "Resource" 
and is described in detail in Appendix A. The dynamic state of a performance of operation "use" is recorded 
by a use frame of class "Use Frame". Use frames are discussed in Appendix B. 

15 

Conditional Execution of Executed Objects 

An executed object is executed conditionally by performance of operation "if or operation "either". Per- 
formance of operation "if by a responding executed object consumes a boolean object and performs the exe- 

20 cuted object if the value of the boolean object is "true." It should be noted that procedures are executed objects, 
i.e., members of mix-in class "Executed", and that the performance of a procedure is discussed above with 
respect to Figures 52Aand 52B. 

Logic flow diagram 6000 (Figure 60) shows the implementation of operation "if as defined by mix-in class 
"Executed". In performing operation "if, the responding executed object pops a boolean object from the current 

25 stack in step 6002. Processing transfers from step 6002 to a boolean test step 6004, in which the boolean object 
popped in step 6002 is compared to "true". If the boolean object is "true", processing transfers from boolean 
test step 6004 to step 6006 in which the responding executed object is performed. Processing transfers from 
step 6006 to exception test step 6010 in which the engine carrying out performance of operation "if" determines 
whether execution of the responding executed object in step 6006 threw an exception. 

30 If no exception is thrown in step 6006, processing transfers from exception test step 601 0 to terminal step 

6008. Additionally, processing transfers from boolean test step 6004 directly to terminal step 6008 if the boo- 
lean object is "false". In terminal step 6008, operation "if completes successfully. If an exception is thrown in 
step 6006, processing transfers from exception test step 6010 to terminal step 6012 in which any exception 
thrown by performance of the responding executed object in step 6006 is thrown, causing operation "if to fail. 

35 The dynamic state of a performance of operation "if" is recorded by a predefined frame, i.e. a member of class 
"Predefined Frame", which is discussed above and in Appendix B. 

One of two executed objects is selected and executed by use of operation "either". An executed object 
performs operation "either" by consuming a second executed object and a boolean object and causing exe- 
cution of the responding executed object if the boolean object s value is "true" and, causing execution of the 

40 second executed object if the boolean object's value is "false." Logic flow diagram 61 00 (Figure 61 ) shows the 
implementation of operation "either" as defined by mix-in class "Executed". 

The responding executed object pops from the current stack a second executed object in step 61 02. Proc- 
essing transfers from step 6102 to step 6104 in which the responding executed object pops from the current 
stack a boolean object. Processing transfers from step 6104 to boolean test step 6106 in which the boolean 

45 popped in step 6104 : ^mpared to "true". If the boolean object is "true", processing transfers from boolean 
test step 6106 to step 08 in which the responding executed object is performed. Conversely, if the value of 
the responding boolean object is "false", processing transfers from boolean step 6106 to step 6110 in which 
the second executed object is performed. Processing transfers from step 6108 or step 6110 to terminal step 
6112. In terminal step 6112, operation "either" terminates, throwing any exception thrown in step 6108 or step 

50 6110. The dynamic state of an executed object performing operation "either" is recorded by a predefined frame. 

An executed object is selected from one or more executed objects and performed by performance of op- 
eration "select". Operation "select" is defined by class "Object" and is performed by an object identifying the 
particular executed object to be performed. Figures 62A and 62B show the interface of the operation "select". 
Figure 62A shows the state of predefined frame 6200 which records the dynamic state of operation "select" 

55 as performed by object 6204. Predefined frame 6200 is part of the execution state of a process (not shown) 
and is shown immediately prior to performance of operation "select". 

Object 6204 is the responder. Predefined frame 6200 has no property "responder" which identifies object 
6204. Instead, object 6204 is identified as the responder by its position within property "procedure" of the frame 
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(not shown) immediately below the current frame on the stack (not shown) that is property "frames" of the cur- 
rent process. Object 6204 is the item of that procedure (not shown) whose position is one less than property 
"position" of that frame. For example, the responder of user-defined frame 5602 (Figure 56C) is the item of 
procedure 5406 whose position is one less than the value of integer 5408. 

5 Stack 6202 (Figure 62A) is the current stack. On stack 6202 are a mark, whose position is indicated by 

letter "M" and which delineates the arguments of the operation, and one or more pairs of objects and associated 
executed objects. For example, stack 6202 contains from top to immediately above the mark, object 6206, exe- 
cuted object 6208, object 6210, executed object 6212. nil 6214, and executed object 6216. Objects 6206, 6210 
and nil 6214 are associated with respective executed objects 6208, 6212 and 6216. 

w The implementation of operation "select" is shown by logic flow diagram 6300 (Figure 63). In step 6302. 

objects 6206-7616 (Figure 62A) and the mark are popped from stack 6202. Processing transfers from step 
6302 to step 6304 in which a dictionary is formed whose keys are objects 6206, 6210 and nil 6214 and whose 
associated values are respective executed objects 6208, 621 2 and 62 1 6. Processing transfers from step 6304 
to step 6306. In step 6306, the executed object whose associated key is equal to responding object 6204 is 

15 retrieved from the dictionary formed in step 6304. The retrieval of a value of a dictionary given a key of the 
dictionary is described in detail in Appendix A. 

Processing transfers from step 6306 to a test step 6308. In test step 6308, the engine carrying out per T 
formance of operation "select" determines whether an executed object is successfully retrieved from the dic- 
tionary. If an executed object associated with a key equal to responding object 6204 is found within the dic- 

20 tionary and retrieved, processing transfers to step 6314. In step 6314, the retrieved executed object is per- 
formed. Processing transfers from step 631 4 to exception test step 6316 in which the engine determines wheth- 
er the performance of the executed object completed successfully in step 6314. 

If performance of the executed object in step 6314 fails and throws an exception, processing transfers 
from exception test step 6318 to terminal step 6320. In terminal step 6320. the exception is thrown, causing 

25 operation "select" to fail. If, on the other hand, the retrieved executed object is performed successfully in step 
6314, processing transfers from exception test step 6318 to terminal step 6316. In terminal step 6316, oper- 
ation "select" completes successfully. 

In test step 6308, if no key equal to responding object 6204 is found in the dictionary formed in step 6304. 
processing transfers from test step 6308 to step 631 0. In step 6310, the executed object contained within the 

30 dictionary whose associated key is a nil. e.g., executed object 621 6 associated with nil 6214, is retrieved. Proc- 
essing transfers from step 6310 to a second test step 631 2 in which the engine determines whether an executed 
object is successfully retrieved in step 631 0. If an executed object within the dictionary with an associated key 
that is a nil is found and successfully retrieved, processing transfers from second test step 6312 to step 6314 
which performs the executed object as described above. 

35 If. on the other hand, no executed object is retrieved in step 6310. no key equal to object 6204 and no key 

that is nil is found in the dictionary and processing transfers from second test step 6312 to terminal step 6316. 
As described above, in terminal step 6316, operation "select" completes successfully. Thus, if no executed 
object is associated with a key equal to the responding object or is associated with a nil, operation "select" 
completes successfully without performing any executed object in the dictionary. 

40 Figure 62B shows the state of select frame 6200 immediately following performance of operation "select" 

by responding object 6204. Performance of operation "select" produces no result as shown by empty stack 
6202 of Figure 62B. 

An executed object is executed repeatedly so long as a condition is met by performance of operation 
"while". The dynamic state of a performance of operation "while" is recorded in a predefined frame 6402 (Figure 

45 64). Executed object 6404 is the responder of operation "while" and is the responding executed object. Exe- 
cuted object 6404 is property "procedure" of predefined frame 6402. Executed object 6406 is property "pre- 
condition" of predefined frame 6402 and is the executed object consumed as an argument as discussed below. 

Operation "while" is performed by responding executed object 6404 which consumes as an argument exe- 
cuted object 6406. Performance of operation "while" is illustrated by logic flow diagram 6500 (Figure 65). In 

50 step 6502, executed object 6406 is popped from the current stack. Processing transfers from step 6502 to step 
6504, in which executed object 6406 is performed. Performance of executed object 6406 in step 6504 pushes 
on to the current stack a boolean which indicates whether responding executed object 6404 is to be performed. 

Processing transfers from step 6504 to exception test step 6506 in which the engine carrying out perfor- 
mance of operation "while" determines whether performance of executed object 6406 throws an exception. If 

55 performance of executed object 6406 throws an exception, processing transfers from exception test step 6506 
to terminal step 6508 in which the exception is thrown by operation "while" causing operation "while" to fail. 
If, on the other hand, executed object 64Uo is performed successfully, processing transfers from exception 
test step 6506 to step 6510. 
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In step 6510. a boolean is popped from the current stack. Processing transfers from step 6510 to true test 
step 6512. In true test step 6512, the boolean popped from the current stack is compared to "true". If the boo- 
lean is "true", processing transfers from true test step 6512 to step 6514 in which responding executed object 
6406 is performed. Processing transfers from step 6514 to a second exception test 6516 in which the engine 
5 determines whether performance of executed object 6404 throws an exception. 

If performance of executed object 6404 in step 6514 throws an exception, processing transfers from sec- 
ond exception test step 6516 to a continue test step 6522. In continue test step 6522, the thrown exception is 
compared to an internal exception "continue", which is thrown by execution of selector "continue" as described 
below and in Appendix A. As described below in greater detail, execution of selector "continue" terminates an 
10 iterative performance of a procedure and initiates a new iterative performance of the procedure. If the exception 
thrown in step 6514 is internal exception "continue", processing transfers from continue test step 6522 to step 
6504, which is described above. 

Conversely, if the exception thrown in step 6514 is not internal exception "continue", processing transfers 
from continue test step 6522 to a break test step 6524. In break test step 6524, the exception thrown in step 
15 6514 is compared to an internal exception "break", which is thrown by execution of selector "break" as descri- 
bed below and in Appendix A. As described below in greater detail, execution of selector "break" terminates 
an iterative performance of a procedure without initiating a new iterative performance of the procedure. If the 
exception thrown in step 6514 is internal exception "break", processing transfers from continue test step 6522 
to terminal step 6520, in which operation "while" completes successfully as described below. 
20 Conversely, if the exception thrown in step 6514 is not internal exception "break", processing transfers 

from break test step 6524 to terminal step 6518. In terminal step 6518. the exception thrown in step 6514 is 
thrown causing operation "while" to fail. 

If, on the other hand, performance of executed object 6404 succeeds and no exception is thrown in step 
6514, processing transfers from second exception test step 6516 to step 6504 in which executed object 6406 
25 is again performed. 

Performance of steps 6504, 6506, 6510, 6512, 6514, 6516, and 6522 is repeated until performance of exe- 
cuted object 6406 produces a boolean whose value is "false" or until an exception is thrown in step 6508 or 
step 6518. If performance of executed object 6406 produces a boolean that is "false", processing transfers 
from true test step 6512 to terminal step 6520 in which operation "while" completes successfully. Thus, pro- 
30 cedure 6406 is repeatedly performed while performance of executed object 6406 produces a "true" boolean. 

Thus, operations "if, "either", "select" and "while" provide the disclosed set of computer instructions sub- 
stantial decision making capabilities. 

Exception Handling Features 

35 

As discussed in greater detail in Appendix A, an executed object which performs operation "do" is thereby 
performed, and if performance of the executed object throws an exception, the exception is thrown by oper- 
ation "do", causing operation "do" to fail. The propagation of exceptions is illustrated in steps 5210 and 5212 
of logic flow diagram 5200 (Figure 52A) as discussed above. Failure of a performance of an executed object 

40 generally causes the failure of any executed object invoking, either directly or indirectly, the performance. Any 
exception which causes operation "live" of a process to fail causes destruction of the process. It is therefore 
preferred that instructions be provided which detect and prevent the propagation of exceptions. 

Af irst executed object, e.g., a procedure, invoking the performance of a second executed object is capable 
of preventing failure of the first executed object due to an exception thrown by the second executed object by 

45 "catching" any exception thrown by the second executed object. To "catch" an exception is to detect the throw- 
ing of the exception and to direct that specific action be taken in such an event. An exception which is thrown 
by the second executed object and which is caught by the first executed object does not cause the first exe- 
cuted object to fail. 

An exception thrown by performance of an executed object is caught by causing performance of the exe- 
50 cuted object by use of operation "catch" in the place of operation "do". An executed object, whose performance 
is caused by operation "catch", is performed as if the executed object were performing operation "do" except 
that certain exceptions thrown by performance of the executed object do not cause operation "catch" to fail. 
In such a case, the exception is pushed on to the current stack and returned as a result. 

The interface of operation "catch" is shown by Figures 66A and 66B. Figure 66A shows the state of catch 
55 frame 6602, which records the dynamic state of operation "catch" as defined by mix-in class "Executed", im- 
mediately prior to performance of operation "catch" by executed object 6604. Catch frame 6602 is part of the 
execution state of a process (not shown). Executed object 6604 is the responding executed object and is prop- 
erty "procedure" of catch frame 6602. Performance of operation "catch" consumes a single argument, class 
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object 6608 which is at the top of stack 6606. Stack 6606 is the current stack. Stack 6606 is property "stack" 
of the topmost user-defined frame (not shown) below catch frame 6602 on the stack (not shown) that is prop- 
erty "frames" of the current process. Class object 6608 represents class "Exception" or a subclass thereof. 
The implementation of the operation "catch" is shown by logic flow diagram 6700 (Figure 67). Class object 

5 6608 is popped from stack 6606 and thereby consumed in step 6702. Processing transfers from step 6702 to 
step 6704 in which executed object 6604 is performed. Processing transfers from step 6704 to exception test 
step 6706 in which the engine carrying out performance of operation "catch" determines whether performance 
of executed object 6604 throws an exception. If performance of executed object 6604 does not throw an ex- 
ception, processing transfers from exception test step 6706 to step 6708. In step 6708, a nil is pushed on to 

10 stack 6606. Processing transfers from step 6708 to terminal step 6710 in which operation "catch" completes 
successfully. 

If execution of executed object 6604 in step 6704 fails and throws an exception, processing transfers from 
exception test step 6706 to member test step 6712. In member test step 6712, the engine checks membership 
of the exception thrown in step 6704 in the class represented by class object 6608. If the thrown exception is 

15 not a member of the class represented by class object 6608, processing transfers from member test step 6712 
to terminal step 6714. In terminal step 6714, the exception thrown in step 6704 is thrown by operation "catch" 
and operation "catch" fails. 

If the thrown exception is a member of the class represented by class object 6608, processing transfers 
from member test step 6712 to step 6716. In step 6716, the exception thrown in step 6704 is pushed on to 

20 stack 6606 and processing transfers from step 6716 to terminal step 6710. As described above, in terminal 
step 6710, operation "catch" completes successfully. Thus, the thrown exception is caught, and operation 
"catch" succeeds and does not propagate the thrown exception. 

Figure 66B shows the state of catch frame 6602 immediately following performance of operation "catch" 
by procedure 6604. At the top of stack 6606 is exception 6610 which is the exception thrown by performance 

25 of procedure 6604 if performance of procedure 6604 failed. In such a case, exception 6610 is a member of 
the class represented by class object 6608 (Figure 66A). In place of exception 661 0 (Figure 66B) on stack 6606 
is a nil (not shown) if performance of procedure 6604 succeeded. Thus, the disclosed set of computer instruc- 
tions is provided with means for detecting and handling exceptions. 

30 Looping Features 

The disclosed computer instruction set provides means for repeatedly performing an executed object, e.g., 
a procedure, facilitating performance of repetitive tasks. Operation "while" discussed above is one example 
of a looping feature. Additionally, an executed object is performed repeatedly using operations "loop" and "re- 
35 peat". 

Operation "loop" performs an executed object indefinitely by repeatedly performing the responding exe- 
cuted object. Performance of operation "loop" by an executed object consumes no arguments and produces 
no result. Performance of operation "repeat" by an executed object consumes an integer argument and pro- 
duces no result, performing the responding executed object a number of times equal to the value of the integer 

■to argument consumed. Each performance of the responding executed object in the course of performing oper- 
ation "loop" or operation "repeat" is herein called an "iterative performance" of the executed object. 

Logic flow diagram 6800 (Figure 68) shows the implementation of operation "loop" as performed by the 
responding executed object. The responding executed object is performed in step 6802. Processing transfers 
from step 6802 to exception test step 6804 in which the engine carrying out performance of operation "loop" 

45 determines whether performance of the responding executed object throws an exception. If no exception is 
thrown, i.e., if the responding executed object is performed successfully, processing transfers from exception 
test step 6804 to step 6802 in which the responding executed object is performed again. Otherwise, if perfor- 
mance of the responding executed object throws an exception, processing transfers from exception test step 
6804 to continue test step 6806. In continue test step 6806, the exception thrown by performance of the re- 

50 sponding executed object in step 6802 is compared to internal exception "continue". 

Internal exceptions "continue" and "break" are thrown by execution of selectors "continue" and "break", 
respectively, which are discussed more completely below and in Appendix A. These exceptions are called "in- 
ternal" because internal exceptions "continue" and "break" are detected by an engine which takes action in 
response thereto. A third internal exception, i.e., internal exception "succeed" which is thrown as a result of 

55 executing selector "succeed", is discussed below. Internal exceptions are not caught by operation "catch" and 
do not cause operation "live" to fail, thereby causing destruction of a process, except as described below. 

If the exception thrown by performing the executed object in step 6802 is internal exception "continue", 
processing transfers from continue test step 6806 to step 6802 in which the responding executed object is per- 
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formed again. Otherwise, if the exception thrown in not internal exception "continue", processing transfers 
from continue test step 6806 to break test step 6808. In break test step 6808. the exception thrown by per- 
forming the responding executed object is compared to the internal exception "break". If the exception thrown 
by performance of the executed object in step 6802 is internal exception "break", processing transfers from 

5 break test step 6808 to terminal step 6810 in which operation "loop" completes successfully. Otherwise, if the 
exception thrown is not internal exception "break", processing transfers from break test step 6808 to terminal 
step 6812 in which operation "loop" fails and the exception thrown by performance of the responding executed 
object in step 6802 is thrown by operation "loop". 

Figure 69 shows a repeat frame 6902 which records the dynamic state of a performance of operation "re- 

10 peat" by executed object 6904. Repeat frame 6902 is a part of the execution state of a process (not shown). 
Repeat frame 6902 includes properties "procedure", "repetitions", "repetitionsSoFar" and "position". Executed 
object 6904 is the responder of operation "repeat" and is property "procedure" of repeat frame 6902. Integers 
6910 and 6911 are properties "repetitionsSoFar" and "repetitions", respectively, of repeat frame 6902. Integer 
6910 represents the number of completed iterative performances of executed object 6906, and integer 6911 

15 represents the total number of iterative performances specified by the consumed integer argument. 

Logic flow diagram 7000 (Figure 70) shows the implementation of operation "repeat" as performed by exe- 
cuted object 6904. In step 7002, integer 6910 is initialized to zero and integer 6911 is initialized to the value 
of the integer consumed as an argument. Processing transfers from step 7002 to test step 7004 in which integer 
6910 is compared to integer 6911. If integer 6910 is greater than or equal to integer 6911. processing transfers 

20 from test step 7004 to terminal step 7018 in which operation "repeat" completes successfully. Therefore, if the 
integer consumed is non-positive, performance of the operation "repeat" has no effect. Otherwise, if integer 
691 0 is less than integer 691 1 , processing transfers from test step 7004 to step 7005 in which integer 691 0 is 
incremented. Processing transfers from step 7005 to step 7006 in which an integer object whose value is that 
of integer 6910 is pushed on to the current stack. Processing transfers from step 7006 to step 7008 in which 

25 responding executed object 6904 is performed. It is up to executed object 6904 to pop the integer from the 
current stack. In other words, if performance of executed object 6904 does not pop the integer from the current 
stack, the integer remains on the current stack during performance of operation "repeat". 

Processing transfers from step 7008 to an exception test step 7010 in which the engine carrying out per- 
formance of operation "repeat" determines whether performance of responding executed object 6904 throws 

30 an exception. If no exception is thrown, processing transfers from exception test step 7010 to test step 7004. 
Conversely, if an exception is thrown, processing transfers from exception test step 7010 to continue test step 
7014 in which the exception is compared to internal exception "continue". If the exception thrown is internal 
exception "continue", processing transfers from continue test step 7014 to test step 7004. Thus, if no exception 
is thrown in step 7008 or if the exception thrown is internal exception "continue", processing transfers to test 

35 step 7004 in which integer 69 1 0 is again compared to integer 6911. Thus, execution of selector "continue" pre- 
maturely terminates an iterative performance of responding executed object 6904 without affecting subse- 
quent iterative performances in performance of operation "repeat". 

If, in continue test step 7014, the engine determines that performance of responding executed object 6904 
in step 7008 throws an exception other than internal exception "continue", processing transfers from continue 

40 test step 7014 to break test step 7016. In break test step 7016, the exception thrown is compared to internal 
exception "break". If the exception thrown is internal exception "break", processing transfers from break test 
step 7016 to terminal step 7018. In terminal step 7018, operation "repeat" completes successfully. Thus, exe- 
cution of selector "break" terminates an iterative performance of responding executed object 6904 and suc- 
cessfully terminates performance of operation "repeat", aborting any remaining subsequent iterative perfor- 
ms mances in performance of operation "repeat". 

If the exception thrown is not internal exception "break", processing transfers from break test step 7016 
to terminal step 7020. In terr : il step 7020, the exception thrown by performance of responding executed ob- 
ject 6904 is thrown by oper- 'repeat" causing operation "repeat" to fail and to propagate the exception. As 
discussed above, operation ;ich" can be used to prevent the propagation of the exception. 

50 Once integer 691 0 is decremented in step 7005 to a value less than or equal to zero, processing transfers 

from test step 7004 to terminal step 7018 in which operation "repeat" completes successfully. Performance of 
operation "repeat" by an executed object produces no results other than those resulting from performance of 
the executed object in step 7008 of Figure 70. 

Execution of selector "continue" throws internal exception "continue" which is caught by operations "while", 

55 e.g., in continue test step 6522 (Figure 65); "loop", e.g., in continue test step 6806 (Figure 68); and "repeat", 
e.g., in continue test step 7014 (Figure 70). The throwing of internal exception "continue" by execution of se- 
lector "continue" terminates an iterative performance of an executed object performing operation "while", "loop" 
or "repeat". As described more completely above, detection of internal exception "continue" during perfor- 



68 



EP 0 634 719 A2 



mance of operation "while", "loop", or "repeat" causes a subsequent iterative performance of the responding 
procedure, e.g., in continue test steps 6522. 6806, and 7014 of Figures 65, 68, and 70, respectively. 

Execution of selector "break" throws internal exception "break" which is caught by operations "while", e.g., 
in break test step 6524 (Figure 65); "loop", e.g., in break test step 6808 (Figure 68); and "repeat", e.g., in break 
5 test step 7016 (Figure 70). As with the throwing of internal exception "continue" discussed above, the throwing 
of internal exception "break" terminates an iterative performance of an executed object in the course of per- 
forming operation "while", "loop", or "repeat". However, throwing internal exception "break" terminates perfor- 
mance of operation "while", "loop", or "repeat" rather than causing a subsequent iterative performance of the 
responding executed object. 

w Internal exceptions "continue" and "break" are distinguishable from other exceptions only in the context 

of operations "while", "loop", and "repeat". Therefore, in the context the following discussion of internal excep- 
tions "continue" and "break", operations "while", "loop", and "repeat" are collectively referred to herein as "the 
relevant operations". As each of the relevant operations detects and takes action in response to internal ex- 
ceptions "continue" and "break", internal exceptions "continue" and "break" are not thrown by either of the rel- 

15 evant operations as are other exceptions. Figure 71 serves as an illustrative example. 

Stack 7104 is a property of process 7102 and represents the thread of execution of process 7102. User- 
defined frame 7 1 06 is at the bottom of stack 71 04 and records the dynamic state of a performance of operation 
"live". The remaining contents of stack 7104 from bottom to top are repeat frame 7108. predefined frame 7110, 
which records the dynamic state of a performance of operation "loop", and user-defined frame 7112. Thus, 

20 operation "live" in Figure 71 caused performance of operation "repeat" which caused performance of operation 
"loop" which caused performance of yet another feature. 

Suppose that performance of the feature, whose dynamic state is recorded by user-defined frame 7112, 
executes selector "continue" or selector "break". As discussed above, execution of either selector "continue" 
or "break" throws a corresponding internal exception. Any operation which is not designed to catch these in- 

25 ternal exceptions, i.e.. any operation other than either of the relevant operations, behaves as if an ordinary 
exception has been thrown (see discussion above regarding exception test step 5210 and terminal step 5212 
of Figure 52A). In this situation, the internal exception is propagated by performance of the feature represented 
by user-defined frame 7112 and is caught by performance of operation "loop" represented by predefined frame 
7110 in the manner discussed above. The internal exception is not propagated by operation "loop" represented 

30 by loop frame 7110 and therefore has no effect on the performance of operation "repeat" represented by repeat 
frame 7108. 

If no relevant operation is currently being performed, i.e.. is not present on stack 7104, execution of either 
selector "continue" or selector "break" produces an exception of class "Loop Missing". An exception of class 
"Loop Missing" is not an internal exception and is therefore propagated like any other exception. 

35 If internal exception "succeed" is thrown, i.e., if selector "succeed" is executed, performance of the current 

method terminates successfully. It should be noted that, since predefined features are implemented directly, 
i.e., in the computer instructions which collectively form an engine, only user-defined features are implemented 
by method objects. Therefore, if operation "loop", the dynamic state of a performance of which is recorded in 
predefined frame 7110 (Figure 71), executes selector "succeed", an internal exception "succeed" is thrown, 

40 terminating performance of operation "loop". Since operation "loop" is predefined, operation "loop" does not 
catch internal exception "succeed" and therefore propagates internal exception "succeed", causing the termin- 
ation of operation "repeat", the dynamic state of a performance of which is recorded in repeat frame 7108. Sim- 
ilarly, as operation "repeat" is predefined, operation "repeat" does not catch internal exception "succeed", 
causing the termination of operation "live", the dynamic state of a performance of which is recorded in user- 

45 defined frame 7106. However, since operation "live" has no predefined implementation, operation "live" ter- 
minates successfully, i.e., does not fail by throwing an exception. Similarly, if the feature whose method is 
the subject of user-defined frame 7112 throws internal exception "succeed", i.e., executes selector "succeed", 
the feature terminates successfully and internal exception "succeed" is caught. In such a case, internal ex- 
ception "succeed" has no effect on predefined frame 7110, repeat frame 7108, and user-defined frame 7106. 

50 The operations discussed above, i.e., operations "do", "if", "either", "while", "select", "catch", "loop", and 

"repeat" are performed in the context of the current method. As discussed above, predefined operations are 
not implemented by method objects. The above-listed operations are all predefined and are therefore not im- 
plemented by method objects. The performance of the above-listed operations in the context of the current 
method is easily described by way of example. 

55 Suppose, for example, that the feature whose method is the subject of frame 7112 (Figure 71) requests 

performance of one of the above-listed predefined operations, the performance of which is recorded in a pre- 
defined frame (not shown) immediately above user-defined frame 7112 on stack 7104. During performance 
of the predefined operation, property "stack" of user-defined frame 7112 remains "the current stack." Thus, 
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performance of the predefined operation pops arguments from, and pushes results on to, property "stack" of 
user-defined frame 7112. Therefore, the predefined operations listed above are performed in the context of 
the current method. 

The operations discussed above, i.e., operations "do", "if, "either", "while", "select", "catch", "loop", "re- 
peat", "continue" and "break", provide the object-oriented instruction set of the present invention with a sub- 
stantial degree of generality and versatil ity. Thus, agents are capable of employing sophisticated logic in trav- 
eling from one place to another, depositing and gathering information by interacting with agents found at va- 
rious places. 

Thus, a novel set of computer processes are provided which can direct their own movement through a com- 
puter network, can send nr.. : nle active copies of themselves throughout the network and can interact with 
other computer processes fou .d at remote network nodes to thereby transfer information between processes. 
The disclosed set of computer instructions of which the novel set of computer processes are formed is portable 
and general. The set of computer instructions is implemented uniformly on each node of the computer network. 
Classes are made objects within the disclosed instruction set. The instructions of a process in the present in- 
vention are interpreted rather than compiled. Control constructs are provided for resource management, de- 
cision handling, exception handling, and loop constructs. Thus, a portable and general set of computer instruc- 
tions is provided from which the novel set of computer processes are constructed. 

It should be understood that, while a particular set of computer instructions is described herein and in the 
Appendices, the present invention is not limited to the functionality of the instructions described. Therefore, 
the scope of the present invention shall be limited only by the claims which follow. 
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1 INTRODUCTION 

The three major elements of the Teiescript technology 
are introduced in this section of this appendix: the 
10 Teiescript Instruction Set, i.e. the subject of this 
appendix; the Teiescript Engine, which implements the 
Instruction Set; and the Teiescript Network, formed by 
interconnecting Engines. 

1 • 1 Teiescript Instruction a^r 
15 The Teiescript Instruction Set, which is sometimes 

referred to herein as the "Instruction Set", is a set of 
computer instructions which collectively form a 
programming language whose intended field of application 
is distributed systems and applications. The Instruction 
20 Set is both object-oriented and interpreted. In 

Microfiche Appendices E and F, the Instruction Set is 
sometimes referred to as "the Language". 

The most distinctive classes built into the 
Instruction Set are classes "Agent" and "Place". An 
25 agent, i.e. a computer process chat is a member of class 
"Agent", is an active object that can examine and modify 
itself, transport itself from one place in a network to 
another, and interact with the other agents it finds 
there. This power is counterbalanced by permits, which 
30 enable either a programmer or an administrator to grant 
only particular capabilities to particular agents on 
particular occasions. A place, i.e. a computer process 
that is a member of class "Place", is an active object 
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that can examine and modify itself and that serves as a 
venue for agents and a context in which they can interact. 

An agent goes to a place and there interacts with the 
place and other occupants of the place. Agents and places 

5 cannot interact at a distance. Thus the Instruction Set 
implements remote programming (RP) , not the more familiar 
remote procedure calling (RPC) paradigm. RP improves upon 
RPC by enabling system elements to interact without 
communicating, improving the performance of the 

0 interactions by reducing their latency. Equivalent ly, RP 
enables system elements to customize one another by 
stationing their own agents- -and thus themselves- - in one 
another's domain. 

The Instruction Set strives to achieve these 

5 characteristics : 
Safety 

• The Instruction Set prevents a process from exceeding 
its permit, interfering with another process without 
the latter' s permission, or directly manipulating the 

0 computer on which the process runs. This helps to 

avoid viruses. 
Portability 

• The Instruction Set makes no concessions to the 
hardware or software constraints or peculiarities of 

5 a particular computer system. This enables a process 

to be executed anywhere within or around a network. 
Extendibilitv 

• The Instruction Set gives to types of information 
object defined by the programmer the same stature as 

3 those built into the Instruction Set. This enables 

extension of the Instruction Set for particular 
purposes . 
Elevation 

• The Instruction Set draws no distinction between 

> volatile and non- volatile storage. Every information 

object is inherently persistent. This increases a 



80 



EP 0 634 719 A2 



process level of abstraction and decreases the 
process' size. 

1 . 2 Telescript Engine 

A program written in the Instruction Set is brought 

5 to life by a Telescript Engine, which is somet imes 

referred to herein as an "Engine", which interprets the 
instructions the program contains. Such a program is 
called a telescript. One Engine can interpret many 
telescripts concurrently . 

0 An Engine can implement the abstractions of the 

Instruction Set without directly relying upon the hardware 
or operating system of the computer on which the Engine 
runs. The Engine does this using standard interfaces to* 
the communication, storage, and other subsystems the 

5 Engine requires of the platform. These form the 

Telescript Communication Application Programming Interface 
(API) which is attached as Appendix C and is a part of 
this disclosure and is incorporated herein in its entirety 
by reference . 

3 An Engine can implement privileged escapes from the" 

abstractions of the Instruction Set. Such escapes enable 
the construction, external to the Engine, of operational, 
administrative, and managerial (0AM) tools. Such tools 
are vital to the success of large-scale communication 

5 systems . 



1 . 3 Telescript Network 

Two or more Engines can be interconnected. The 
resulting Telescript Network, which is herein sometimes 
called the "Network" is the universe within which agents 
travel. The Network encompasses computer systems that 
would be considered clients of other networks, not parts 
of them. 

A computer system is a part of the Network only if 
the system incorporates an Engine and thus provides places 
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from and to which agents can go. This requirement makes 
the Network homogeneous with respect to the structure, as 
well as the transport, of information. 

Engines are interconnected so that they can move 
5 agents among themselves. Agents are serialized, or 
encoded, for this purpose according to the Telescript 
Encoding Rules described in Appendix B. The resulting 
octet string is transported between Engines as prescribed 
by the Platform Interconnect Protocol which is attached as 
L0 Appendix F as a part of this disclosure and is 
incorporated herein in its entirety by reference. 

1 . 4 This Appendix 

This appendix is described as follows. 

1.4.1 Scope 

.5 This appendix defines Version 0 . 8 of the Instruction 

Set. The Telescript Encoding Rules, the Telescript 
Protocol, and che Telescript API are all beyond the scope 
of this appendix and are the subject of respective 
Appendices B, F, and C. 

0 One may view the Instruction Set as an instruction 

set for a virtual machine. From this viewpoint, one can 
readily envision scill higher-level languages, compilers 
for which produce celescripts. General Magic Inc. of 
Mountain View, California is developing such a language 

5 which is called High Telescript. In the context of 
Appendices A-F of this disclosure, the Instruction Set 
itself is sometimes called Low Telescript. 

1.4.2 Conformance 

A manufacturer of an Engine has to satisfy certain 
0 requirements to properly claim conformance to this 
appendix . 

1.4.3 Convent ions 
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These conventions of prose are followed throughout 
this appendix: 

• "The a attribute" means "the attribute whose 
identifier equals a" . 

5 • "Is a key" means "equals a key", and not "is the same 
as a key" . 

• "An x" generally means "a member of X", and not "an 
instance of X" . 

• "Throws x" generally means "throws a member of X" . 
0 • "Whether statement " means " statement iff true " . 

• Iff means "if and only if", as it does in 
mathematics . 

• MSB stands for "most significant bit". 

• LSB stands for "least significant bit". 

5 Note : Throughout this appendix, notes (like this) are 

explanatory; not definitive. 

1.4.4 Organization 

This appendix is divided into eight sections. 
Section l is this introduction. Section 2 introduces the 
0 Instruction Set's major concepts. Section 3 overviews the 
Instruction Set's predefined classes. Section 4 defines 
them in detail. Section 5 defines the Instruction Set's 
syntax . 

Section 6 defines the conventions followed by the 
5 formal definitions of the interfaces to the predefined 
classes. Section 7 comprises those formal definitions. 
Section 8 shows the part of the class graph that comprises 
the predefined classes and no user-defined classes. 

1.4.5 Road Map 

0 Parts of this appendix are definitive, while others 

are merely informative. The definitive sections are 
Sections 1, 2, 4, and 5. In contrast, Sections 3, 7 and 
3, reorganize material in Section 4, while Section 6 
duplicates aspects of High Telescript. 
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Different audiences require different parts of this 
appendix. Those interested only in the Instruction Set's 
scope and structure need read only Sections 1, 2, and 3. 
A Telescript programmer requires Section 4 as well. A Low 

5 Telescript programmer must master also the portion of 
Section 5 covering character telescripts, while the High 
Telescript programmer need not do so . A High Telescript 
Compiler or Engine implementcr requires the portion of 
Section 5 covering binary telescripts. 

0 For Telescript practitioners, Sections 7 and 3 are 

indispensable references. 



1 ■ 4 • 5 References 

This appendix relies upon these other documents: 

j 106461 

Information tech nology- -Universal Coded Character Set 
lUCSl, ISO/IEC DIS 10646, International Organization 
for Standardization and International 
Electrotechnical Commission, 1990. 

[Unicode] 

The Unicode Stand ard: Worldwide Character Encoding . 
Volume 1, Version l.o, The Unicode Consortium, 
Addison-Wesley , 1991 . 

2 TELESCRIPT CONCEPTS 

The Instruction Set defines a variety of concepts, 
the most important of which are introduced in this section 
of this appendix. These concepts are divided into 
"models". A subsection is devoted to each model. Within 
each subsection, a lesser subsection is devoted to each 
concept in the model . 

Being for remote programming, the Instruction Set 
includes concepts spanning the realms of languages, 
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operating systems, and networks. Conventionally separate, 
these areas, in this instruction set are brought together. 

2 . 1 Models 

The Instruction Set's concepts are divided into 
models. This division serves pedagogic purposes alone and 
is not visible, in any sense, at run time. 

The following models are defined: 

Object 

The "Object" model provides object orientation, e.g., 
objects, references, classes, operations, and exceptions. 

Execut ion 

The "Execution" model provides sequential execution, 
e.g. methods, procedures, and identifiers. 

Process 

The "Process" model provides mult i - tasking, e.g., 
processes, resources, permits, contacts, and ownership. 

Network 

The "Network" model provides network architecture, 
e.g., agents, places, trips, meetings, and telenames. 

Timekeeping 

The "Timekeeping" model provides means for keeping 
time, e.g., times and calendar times. 

Pattern Matching 

The "Pattern Matching" model provides means for 
pattern matching, e.g., patterns. 

The models are presented below in the order in which 
they are listed above. The concepts within each model are 
presented in a logical order. 
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2 . 2 Object Model 

The Instruction Set realizes the "object model" this 
section defines. 



2.2.1 Objects 
5 An object is the Instruction Set's unit of both 

information and information processing. An object is an 
instance of a class. 



Note: An object may be anything at all, either simple, 

e.g., a boolean, or complex, e.g., a dictionary, 
0 either passive, e.g., a string, or active, e.g., 

a process. 

Note: In messaging, the application for which the 

Instruction Set was cc .reived, the objects can 
include the messaging system's component parts, 
5 e.g., its mailboxes and distribution lists; the 

information objects the system transfers, e.g., 
messages and delivery reports; and the elements 
of those information objects, e.g., the fields 
of envelopes. 



0 Persistence 

Every object is "persistent". If the Engine fails 
and subsequently recovers, the only effect upon the object 
is its temporary unavailability. 

Size 

5 Every object has a "size" which is the approximate 

amount of persistent storage the object occupies, measured 
in octets. 

Noce : An object's size may vary from place to place. 

2.2.2 References 
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A "reference" is the means by which an object is 
denoted and accessed. 

Projected vsUnorotected 

A reference is either "unprotected" or "protected". 
5 An unprotected reference enables the object to be changed, 
while a protected reference does not . An unprotected 
reference can be made protected, but not conversely. 

Creation 

There exists one or more references to every object. 
10 Creating an object creates an initial reference to the 

object as well. The reference is protected iff the object 
is immutable. Additional references can be created as 
desired. Created references are protected iff the source 
reference is protected. 

15 Note : Many predefined operations create new references 

to existing objects and return the references as 
results . 

Comparison 

All unprotected references to an object are 
0 equivalent. Changes made using an unprotected reference 
zc an object are made to the object, and thus, in effect, 
to all other references to the object. Ail protected 
references to an object also are equivalent to one 
another . 

5 An unprotected and a protected reference differ in 

two ways which come to light when a protected reference is 
used to request a feature of the object the reference 
denotes. First, if the feature would change the object, 
the feature fails, throwing "Reference Protected". 

0 Second, if the feature returns a reference to- -not a copy 
of- -one of the object's properties, that reference is 
protected. 
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One can determine whether two references denote the 
same object. 

Discarding 

A reference should be discarded when no longer 
needed. If no references to the same object remain, the 
objecc itself is destroyed. 

Vo i d i ng 

The Engine voids references under circumstances this 
appendix defines. A "voided" reference no longer provides 
access to an object. The Engine throws "Reference Void" 
rather than push a voided reference onto the stack. 

2.2.3 Classes 

A "class" defines a set of objects, the class' 
"instances", all having the same interface and the same 
implementation. The class itself has both an interface 
and an implementation, which are potentially unique to the 
class . 

Predefined vs User-defined 

A class is either predefined or user-defined. A 
"predefined" class, built into the Instruction Set and 
defined in this appendix, represents a kind of object 
available to every Telescript programmer. A 
"user-defined" class, defined by the programmer, extends 
the Instruction Set for specific purposes. 

Concrete vs Abstract 

A class is either concrete or abstract. A "concrete" 
class can have instances. An "abstract" class cannot, but 
its subclasses can and often do. A concrete class, or one 
of its implementation superclasses, shall implement each 
feature either native to or inherited by the class. 
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Sealing 

A class, usually concrete, can be sealed. The Engine 
prevents a sealed class frcm having user-defined, but not 
predefined, immediate subclasses. 

5 Creation 

A concrete class can create a new instance given 
initialization parameters describing the new instance. 
Net every instance of every class, however, can be created 
in this way. The remaining ones can be created by first 
.0 creating one instance in this way and then modifying the 
instance's attributes as necessary. 

Conversion 

A concrete class can convert an instance of one class 
to an instance of itself. Not every instance of every 
5 class, however, can be converted to an instance of every 
other class. The definition of operation "convert", and 
the nature of the object conversion produces, depend upon 
the two classes involved. 

Compatibility 

0 A class is embodied as a cited object. One class is 

backward compatible wich another iff the former's 
interface can be created from the latter' s by making only 
changes of the following kinds. First, a feature can be 
added. Second, if in the latter' s interface an attribute 

5 is read-only, that attribute's class can be narrowed to a 
subclass. Third, the class of an argument of an existing 
operation can be widened to a superclass. Fourth, the 
class of the result of an existing operation can be 
narrowed to a subclass. 

0 2 -2.4 Inheritance 
Native vs Inherited 
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All classes, both predefined and user-defined, are 
related to one another by "inheritance". Every class has 
various characteristics. In general, some of a class' 
characteristics are "native" to the class, while others 
are "inherited" from other classes. Inheritance is a 
transitive relationship. A class inherits from a class 
the latter' s inherited characteristics, as well as the 
latter' s native characteristics. Extending the above 
terminology only slightly, an object's native 
characteristics are those native to the class of which the 
object is an instance. 

The Instruction Set sufficiently constrains the 
inheritance relationships among classes that the classes 
and their relationships can be described by simple graphs. 
In such a graph, the nodes represent classes, the arcs 
between nodes the inheritance relationship between the 
classes the nodes represent. 

Subclass vs Superclass 

If one class inherits characteristics from another, 
either directly or indirectly, the former is a "subclass" 
of the latter, and the latter is a "superclass" of the 
former. If one class inherits characteristics from 
another directly, the former is an "immediate subclass" of 
the latter, and the latter is an "immediate superclass" of 
the former . 

An instance of a class is a "member" of that class 
and of its superclasses. 

Flavor 

Some classes are flavors. The "flavors", each of 
which is either abstract or concrete, form a tree as 
follows. The tree's root represents class "Object". Each 
destination node reached by an arc emanating from any 
given source node represents an immediate subclass of the 
flavor that the source node represents. Thus the source 
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node represents an immediate superclass of the flavor 
represented by each such destination node. Each 
destination node reached by way of one or more arcs in 
succession represents a subclass of the flavor that the 
source node represents. Thus the source node represents a 
superclass of the flavor represented by each such 
destination node. 

Note : Flavors provide single inheritance. 

Mix- in 

All other classes are mix-ins. A "mix-in ,f and its 
zero or .more superclasses - -all mix-ins themselves -- form a 
second tree as follows. The tree's root is the mix-in. 
The arcs represent the inverse inheritance relationship 
between the mix-ins that the tree's nodes represent. A 
mix-in is abstract. 

Note: Mix-ins provide a limited form of multiple 

inheritance . 

Class Graph 

The flavors and mix-ins together form a directed 
graph. The graph is constructed in the following two 
steps. First, the arcs in each mix-in tree are reoriented 
to represent the inheritance relationship, rather than its 
inverse. Second, the thusly altered mix-in trees are 
superposed upon the flavors tree. 

Note: There is one, global class graph, achieved by 

identifying classes globally. In any particular 
place, knowledge of the graph may be incomplete. 

Canon i c a 1 Grde r 

A class, either a flavor or a mix-in, and its 
superclasses, both flavors and mix-ins, have a "canonical 
order" which is that of a walk of a third tree. 

The tree is formed as follows. Its root is the class 
in question, its other ncdes the class' superclasses. As 
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in a mix-in tree, the arcs represent the inverse 
inheritance relationship among the classes that the tree's 
nodes represent. 

The walk is a depth- first one in which a class' 
5 immediate superclasses are visited in their canonical 
order, which the class defines. 

Interface vs Implementation 

All of the above can be said about either of three 
sets of class characteristics: the classes' interfaces, 
0 their implementations, or both. This appendix explains, 
either explicitly or implicitly, which of the two sets of 
characteristics is being discussed at any particular point 
within this appendix. 

Note: Mere often than not, the classes' interfaces are 

5 in view. 

2.2.5 Features 

A "feature" is an externally visible characteristic 

of an object. Features enable objects to interact. If 

one object possesses a reference to another, the former 
0 can request a feature of the latter. All instances of a 

class have the same features, defined by the interfaces 

native to or inherited by that class. 

A feature "succeeds", when it is used correctly, and 

"fails", at other times. When the feature fails, an 
5 exception is thrown. 

Attribute vs Operation 

Features are of two kinds, attribute and operation. 
Ncte; Whether a particular feature is made an 

attribute or an operation is, in part, a matter 
0 of taste. 

Sealing 
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A class can seal a feature, either native or 
inherited, thereby preventing the feature's implementation 
by user-defined, but not predefined, subclasses. 

Implementat ion 
5 A class can implement any native feature or any 

inherited feature not sealed by a superclass. In the 
latter case, the class' implementation supersedes the 
superclasses' implementations, if there are any. 

Access 

0 The Engine controls access to a feature. A feature's 

"access" defines the objects that can use the feature, and 
is one of the following: 

public 

Any object can use the feature. 
5 private 

Only the object that has the feature can use it. 
system 

Only the Engine itself can use the feature, which is 
predefined . 

0 2.2.6 Attributes 

An "attribute", an object, is any characteristic that 
one object, the "requester", can ask another or the same 
object, the "responder " , to get and perhaps set. An 
attribute that cannot be set is "read-only". 

5 "aGet" vs "aSet" 

An attribute is exactly equivalent to either one 
operation, if the attribute is read-only, or two, 
otherwise. The first operation, denoted symbolically as 
"aGef, gets the attribute. It has no arguments, and its 
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result is the attribute. The second operation, denoted as 
"OfSet" replaces the attribute with a particular object. 
The cne argument of operation "aSet" is that object, and 
the operation has no result. 

5 Manual vs Automatic 

A class can implement an attribute either manually, 
automatically, or, iff the class is abstract, not at all. 
To "manually" implement an attribute is to provide methods 
for "aGet" and, if the attribute can be set, "aSet". To 

0 "automatically" implement an attribute is to let the 
Engine do so, which it does if the attribute is an 
instance attribute, the class is concrete, and neither the 
class nor its implementation superclasses implement the 
attribute. The Engine implements the attribute with a 

5 property of the same identifier. 

The Instruction Set defines the getting and setting 
of attributes with the aid cf "getAttribute" and 
"setAttribute" , respectively, internal operations an 
argument of which is the attribute's identifier ("a"). 

0 These two operations get and set, respectively, the 

property associated with the attribute, if the latter is 
implemented automatically, or perform the user-defined 
methods for operations "aGet" and "aSet" , otherwise, i.e., 
if the attribute is implemented manually. An attribute's 

5 manual or automatic implementation alike is located using 
the execution model's algorithm for locating the 
implementation of an operation. 

Storace Location 

An attribute that is not read-only behaves by default 
0 as a "storage location". That is, operation "aGet" 

returns the object most recently supplied successfully as 
an argument of operation "aSet". Exceptions to this 
default behavior shall be called out in the prose 
descriptions of particular attributes. 
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Note: Thus if an attribute exhibiting the default 

behavior is constrained to be a member of class 
"Dictionary" , and an instance of a subclass of 
class "Dictionary" is supplied to operation 
5 "*Set" , operation "o<Get" returns that instance 

of that class, not an instance of class 
"Dictionary" . 

Note : All predefined attributes which are read-only 

exhibit the default behavior. 

.0 2.2.7 Operations 

An operation is any task that one object, i.e. "the 
requester", may ask another or the same object, i.e. "the 
responder" , to perform. 

Arguments 

5 The requester supplies the responder with zero or 

more objects, which are the operation's "arguments". An 
operation defines whether the operation's arguments are 
variable or fixed in nurier and, if the latter, how each 
is constrained. 
0 Note : If the arguments are variable in number, none 

may be a mark. 
Note: Of the predefined operations, operations 

"initialize", "makeCiasses " , "select" and "new", 
and no others require a variable number of 
5 arguments . 

Result 

The responder can optionally supply the requester 
with a single object, the operation's "result", if the 
operation succeeds. An operation defines whether there is 
0 a result and, if so, how it is constrained. 

2.2.8 Exceptions 
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An "exception" is an object describing the failure o 
either the performance of a method for a feature or, more 
fundamentally, the execution of one of the executed 
objects that are the items in the method's procedure. 

5 A feature fails when its responder "throws" an 

exception in lieu of any result the responder would have 
returned had the feature succeeded. The feature's 
requester "catches" the exception if the requester wishes 
to react to the exception. Otherwise, the Engine 

0 "propagates" the exception, i.e., causes the requester to 
throw the exception. 

2.2.9 Constraints 

A "constraint" defines restrictions that are placed 
upon other objects, which are the constraint's "subjects" 

5 The possible restrictions include the identifier of the 
class of which the subjects shall be members, that class 
itself, whether the subjects shall be instances of that 
class, whether the subjects are permitted to be nils, the 
class just mentioned notwithstanding, and the subjects' 

0 passage . 

Passage 

An object may be passed between a feature's requeste 
and responder in any of several different ways, which 
determine how the source reference, which the object's 
5 source conveys to the Engine, determines the destination 
reference, which the Engine conveys to the object's 
destination . 

An object's "passage" is one of these identifiers: 
bvRef 

0 The destination reference is the source reference. 

bvUnprotectedRef 
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The destination reference is the source reference, 
but the Engine throws "Reference Protected" if the source 
reference is protected. 

byProtectedRef 

5 The destination reference is a protected reference to 

the object to which the source reference provides access. 

byCopy 

The destination reference is an unprotected reference 
to a copy of the object to which the source reference 
0 provides access. The Engine makes the copy for this 
purpose alone. The copy is owned by either the object's 
destination, if a process, or the object's destination's 
owner, otherwise. 



2.2.10 Properties 

5 An object has zero or more properties. Itself an 

object, a "property" is one element of the object's 
internal state, all of the object's properties, taken 
together, constituting the entire internal state. An 
object's properties are internal to it, and thus can be 

0 directly sensed, examined, and modified by that object 
alone . 

An object's properties are partitioned by class. 
Zero or more are native to the object's class, and zero or 
more to each of the class' implementation superclasses. 
5 A property can be directly sensed, examined, and 

modified by the methods of the class to which the property 
is native, but not by the methods native to other classes, 
not even the class' subclasses or superclasses. 



2.2.11 Copying 

Objects can be copied. A "copy" of one object is 
another object that is indistinguishable from the former 
object except, in general, by means of operation "isSame" 
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and by the fact that the copy can be changed, even if a 
protected reference was used to create the copy. 

A copy generally equals the original from which it 
was fashioned, at least initially. The meaning of "equal" 
5 depends upon the classes of which the original is a 

member. If the class, and thus the copy, are immutable, 
the copy and original remain equal indefinitely. 
Otherwise, they can diverge, as the copy and the original 
are independent . 

L0 A copy is created using operation "copy". The Engine 

creates the copy by requesting operation "'copy" of each 
property of the original. However, if the Engine finds a 
property to be a reference to an object the Engine has 
copied for this purpose already, the Engine does not make 

.5 a second copy of that object, but rather uses a reference 
to the first. 

2.2.12 Object Initialization 

An object's creation entails the object's 
initialization. A method for operation "initialize" can 
0 be native to any class of which the created object is a 
member. The method shall initialize the object's 
properties native to that class. 

Before the Engine requests a method for operation 
"initialize", it sets to nils the properties that are 
5 native to the class to which that method is itself native. 

Initialization Order 

Each method for operation "initialize" shall escalate 
the operation after initializing the properties for which 
the method is responsible, thereby allowing other methods 
0 to do the same. If a method succeeds without escalating 
the operation, the Engine does so for the method. The 
process of escalation visits the class of the created 
object and that class 1 implementation superclasses in 
canonical order. 
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Initial izat ionParameters 

A class' "initialization parameters" are the objects 
that the method for operation "initialize" native to that 
class requires for the operation's performance. If the 
class is a mix-in, it speaks, by its choice of parameters, 
for itself alone. If the class is a flavor, it speaks for 
itself and its implementation superclasses alike. At 
escalation, a class' method for operation "initialize" 
shall have ensured that the parameters of the classes yet 
to follow in the canonical order are on the stack, above 
the topmost mark. After the methods for ail classes have 
been performed, class "Object" throws an exception if any 
parameters remain. 

Initial izat ion Privileges 

A method for operation "initialize" can use a feature 
of the created object after escalation but not before. 
Even then, the object responds as if it were an instance 
of the class to which the method is native, not the class 
of which the object is an instance. The method can use 
other objects' features at any time. 

2.2.13 Object Final izat icn 

An object's destruction entails the object's 
f inalization . A method for operation "finalize" can be 
native to any class of which the destroyed object is a 
member. The method shall finalize the object's properties 
native to that class. 

A method for operation "finalize" can optionally 
discard, and thus perhaps destroy, the properties the 
operation finalizes. If the method does not do so, the 
Engine does. 

Finalization Order 

A method for operation "finalize" does not escalate 
the operation. The Engine performs each method whether or 
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not other methods succeed, visiting the class of the 
destroyed object and its implementation superclasses in 
canonical order. 

2.2.14 Class Construction 

The Instruction Set, unlike many computer languages, 
enables classes to be created at run time via operation 
"makeClasses" . A class is created on the basis of a class 
definition which defines both the class' interface and the 
class ' implement at ion . 

Identifier 3indincs 

A class' interface cr implementation typically 
depends upon other classes which the interface or 
implementation denotes by identifiers. A citation is 
bound to each such identifier with the aid of the 
interface's or implementation's "vocabulary" attribute. 

If the identifier equals that of a predefined class, 
the citation is to that class. Otherwise, if the 
identifier equals a key in the "vocabulary" attribute, the 
citation equals the associated value. Otherwise, the 
citation equals that of the constructed class, except that 
the citation's "title" attribute equals the class' 
identifier. 

Note : The Instruction Set does not define the 

predefined classes' assigned citations. 

Citation Bindings 

A class is bound to a citation with the aid of the 
"privateClasses" and "publicClasses" attributes of the 
current process and the current place, respectively. 

If a cited class is predefined, the cited class is 
found in the Engine itself. If it is user-defined, the 
class is sought, and may or may not be found, in the 
"privateClasses" attribute of the current process, and, 
failing that, in the "publicClasses" attribute of the 



100 



EP 0 634 719 A2 



current place, the class being any that is backward 
compatible with the cited class. 

A class is bound to the citation at one of two times. 
If the class' identifier is an item of a procedure, the 
5 class is sought whenever the identifier is executed. 
Otherwise, the class is sought when the class is 
constructed . 

2 . 3 Execution Model 

The Instruction Set realizes the "execution model" 
0 this section defines. 

2.3.1 Methods 

A "method" is a procedure which is able to separately 
maintain the dynamic state of each of its perf ornances . 
That dynamic state takes the form of a frame. Methods are 
5 used to implement operations, conversions, and selected 
attributes . 

Frame 

A "frame" comprises a stack and zero or more 
variables. Itself an object, a "variable" is one element 

C of the dynamic state of a particular performance of the 
frame's method, all of the frame's properties, taken 
together and with the stack, constituting the entire 
dynamic state. A frame's stack and variables are internal 
to the frame, and thus can be directly sensed, examined, 

5 and modified by the frame's methcd alone. The frame 
itself cannot be manipulated at all. 

Performance 

To "perform" a method is to create a frame, accept an 
offer of objects as the initial items of the frame's 
C stack, set the frame's variables to nils, perform the 
method's procedure, discard the frame,, and, iff the 
procedure succeeded, offer the final items of the frame's 
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stack, having pepped them from that stack before 
discarding the frame. The method's performance succeeds 
or fails if the procedure succeeds or fails, respectively. 
At any point in time, the "current method" is the 
5 method currently being performed, the "current frame" is 
the frame created for that performance, and the "current 
stack", i.e. "the stack", is that of the current frame. 
Note : If the method implements an operation, the 

objects offered as the initial items of the 
.0 stack are the arguments, the topmost of the 

objects offered as the final items the result, 
if there is one. In between these two events, 
the stack holds first the arguments and then the 
result, if there is one, of any operation the 
5 method requests. Items other than the topmost 

item of the stack at completion of the 
operation, if there are any, are objects used 
during performance of the operation to carry out 
intermediate steps of the operation. 

0 2.3.2 Procedures 

A "procedure" comprises zero or more executed 
objects, its "items", which are not among the procedure's 
properties, but rather are more fundamentally a part of 
the procedure. The items are numbered in the range [1, 

5 n] , "n" being the procedure's "length". The procedure is 
"cleared" if its length is zero. An item's number is its 
"position" in the procedure. A "subprocedure " comprises 
zero or more items in adjacent positions within a 
procedure . 

0 Performance 

To "perform" a procedure is to execute its items 
sequentially, in order of increasing position, in the 
current frame. The procedure's performance either 
"succeeds", if each item is executed successfully, or 
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"fails", otherwise. If -he execution of any item fails, 
no remaining item is executed. 

2.3.3 Executed Objects 

An "executed" object is permitted as an item of a 
5 procedure . 

Performance 

To "perform" an executed object other than a 
procedure is to execute it. 

Execution 

0 To "execute" an executed object is tc do things that 

depend upon whether the executed object is an identifier, 
a modifier, a selector, or something else. Execution 
either "fails", if the Engine throws an exception, or 
"succeeds", otherwise. 

5 Any executed object other than an identifier, a 

modifier, or a selector is executed by pushing onto the 
stack a protected reference to the executed object. 
Note: The executed objects in question in the 

preceding paragraph are bits, bit strings, 

0 booleans, characters, integers, marks, octets, 

octet strings, procedures, reals, and strings. 

2.3.4 Identifiers 

A particular class, feature, property, or variable is 
denoted by an identifier, as are other constructs and 
5 objects in the Instruction Set. 

Ident if ier 

An "identifier" distinguishes one object fror others 
within its scope by means of the identifier's "text", a 
string whose length is at least one. 

0 Qualified Identifier 
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A "qualified identifier" distinguishes zero or more 
implementations of a feature from zero or more other 
implementations of the same feature. A qualified 
identifier denotes the feature by means cf the text of it 
5 identifier. It denotes the implementations- -those either 
native to or inherited by a class--by means of the text o 
the class' identifier, which is the qualified identifier's 
"qualifier" . 

Scooe 

0 No two identifiers having the same scope shall be 

equal . 

Class 

A class cited by an interface or an implementation is 
denoted by an identifier whose scope is all classes cited 
5 by that interface or implementation. 

Feature 

A feature of an object is denoted by an identifier 
-vhose scope is all features whether native to or inherited 
by the class of which the object is an instance. 

0 Property 

A property of an object is denoted by an identifier 
whose scope is all properties native to the class to which 
the property in question is itself native. 

Variable 

5 A variable of a frame is denoted by an identifier 

whose scope is all variables defined by the method to 
whose performance the frame pertains. 
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Svntax 

A text cr a qualifier shall exclude the characters in 
Table A. 1. 



TABLE A. 1 




Characters 


Notes 










\j ^ j u \s \j j r u v l r 


rVo rt^ ^ I X , 






Bit 7 one. 


Soaces 


Various 


See [Unicode] §4.2. 
U+0020, U+G0A0, 
etc . 


Symbols and 
Punctuat icn 


U+002I -- U+002F 


As in ASCII . 




U+C03A U^CC40 


As in ASCII . 




U+G05B -- U+005E 


As in ASCII. 




U+0060 


As in ASCI I . 




U-007B U+007F 


As in ASCII. 




U-i-COAl U-00BF 


In Latinl. 




U+0CD7 & U+00F7 


Multipl icac ion 
("X") and division 
U) signs 




U^2000 U+2FFF 


Assigned symbols. 


Private Use 
Characters 


LUE30G -- U-t-FDFF 




Special Characters 


U*FFF 0 - - "J^FFFD 
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5 The first character of a text or a qualifier shall 

exclude the characters in Table A. 2, as well as those in 
Table A.l. 



10 



TAELE A. 2 




Characters 


Notes 


Decimal Diaits 


Various 


See [Unicode] §4.1. 
U+0030-- U+0039, 
etc . 


Non-sDacinq Marks 


Various 


See [Unicode] §4.5. 



20 



Note : When one programs in High Telescript, the 

privilege of assigning identifiers the first 
25 character of whose text is an underscore (■" " ) 

10 ■ (U+005F) is reserved for the High Telescript 

Compiler itself. 



30 2.3.5 Static Substitution Rules 

A procedure is performed as if the substitutions in 
Table A. 3 below had been made. Wherever a subprocedure in 
15 the first column appears in the procedure, the 
35 subprocedure in the same row of the second column replaces 

it . 

Table A. 3 defines each subprocedure using the 
non- terminals used to define telescripts. In the table's 
40 20 first section, "Identifier" stands for either itself or 

"Qldentif ier " . In the second section, "Identifier" stands 
for itself alone. 



45 



50 



55 
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TABLE A. 3 


Subprocedure 


Substituted Subprocedure 


SetAttribute Identifier 


Mention Identifier Swap 
"setAttribute " 


UseStack Identifier 


UseStack Ident if ier 1, : 






Get Class Identifier 


Mention Identifier Self 
"getCiass" 


Get Property Identifier 


Mention Identifier Self 
" get Property " 


GetVariable Identifier 


Mention Identifier Self 
"get Variable" 


SetProperny Identifier 


Mention Identifier Self 
" set Property " 


SetVariabie Identifier 


Mention Identifier Self 
" setVariable" 


Mention ExecutedCbj ect 


Mention "ExecutedObject 2 " 



"This substitution applies iff the identifier is neither 
that of operation "protect" nor opeaticn "ref" . 



: This substitution is an identity. 

If asked to create a procedure having modifiers 
arranged in subprocedures other than those in Table A. 3 or 
Table A. 4 below, the Engine throws an exception. 

An internal operation, discussed in Section 3.2.12 of 
this appendix, succeeds only if requested as the result of 
one of the substitutions in Table A. 3 or Table A. 4. An 
internal operation is otherwise inaccessible. 
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2.3.6 Dynamic Substitution Rules 



A procedure is performed as if the substitutions in 
Table A. 4 had been made as well. In Table A. 4, 
"Identifier" stands for either itself or "Qldent if ier " . 



TABLE A. 4 


Subprocedure 


Substituted Subprocedure 


Identifier 


Mention Identifier Swap 
"getAttribute" 1 


Demarcate Identifier 


Mention Identifier Swap 
Demarcace "ge tAtt ribute " ! 


Demarcate Identifier 


Demarcate Identifier 2 




■ 



'This substitution applies iff the identifier denotes an 
attribute . 



: This substitution, an identity, applies iff that of Note 1 
does net, i.e., if the identifier does not denote an 
attribute . 



2-3.7 Selector Execution 

A "selector" achieves a special execution effect. 
A selector is executed as follows: 

break 

Makes operation "loop", "repeat", or "while" succeed. 
"Loop Missing" is thrown if neither operation is being 
performed . 

client 

Pushes onto the stack an unprotected reference to the 
current client. The "current client" is either the object 
requesting the feature the current method implements, 
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unless the requester is the Engine itself, e.g., if the 
feature's access is "system", or a nil, otherwise. 

cont inue 

Makes operation "loop", "repeat" , or "while" begin 
its next performance, if any. "Loop Missing" is thrown 
neither operation is being performed. 

escalate 

Is the same as executing an identifier for the 
operation that the current method implements, with these 
exceptions. Before method selection, the Engine throws 
"Escalation Invalid" if the requester is not the 
responder. During method selection, the Engine bypasses 
the class to which the current method is native. The 
operation has been escalated. 

here 

Pushes onto the stack an unprotected reference to t 
current place. The "current place" is either the place 
the current process occupies, unless the process is an 
engine place, or a nil, otherwise. 

process 

Pushes onto the stack an unprotected reference to t 
current process. The "current process" is that of which 
the current method's performance is dynamically a part. 

self 

Pushes onto the scack a reference to the current 
object. The "current object" is that performing the 
current method. The reference is protected iff a 
protected reference was used to request the current 
method's performance. 

succeed 
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Causes the current method to succeed without its 
remaining items having been executed. The attribute or 
che operation's result, if there is one, shall be on the 
stack . 

5 2.3.8 Modifier Execution 

A modifier alters the execution of the item that 
follows it in a procedure. 

The execution of various modifiers is provided for by 
the substitution rules. A modifier that the -substitution 
.0 rules leave intact is executed as follows: 

demarcate 

Causes the following identifier, or qualified 
identifier, to be executed with these change. If the 
stack does not include a mark, the Engine throws "Mark 

.5 Missing". If the number of arguments required by the 
operation that the identifier denotes is fixed and less 
than the number of objects above the mark, the Engine 
throws "Argument Invalid". Otherwise, if the number of 
arguments is fixed and greater than the number of objects 

0 above the mark, the Engine inserts in the stack, between 
the mark and the objects supplied, as many nils are there 
are arguments missing. The Engine then excludes the mark 
from the stack and, if the operation succeeds but does not 
produce a result, returns a nil to the requester, in place 

5 of a result. 

mention 

Avoids executing the object following the "mention" 
modifier, pushing a protected reference to that object 
onto the stack instead. 

0 useStack 

Pushes onto the stack a reference to the stack itself 
before executing the following object. 
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10 



15 



25 



30 



40 



45 



2.3.9 I dent i f ier Execution 

The execution of an identifier for a class, an 
attribute, a property, or a variable is provided for by 
the substitution rules described above with respect to 
Tables A. 3 and A. 4 . 



Identifier 

An identifier chat the substitution rules leave 
intact- -one for an operation- - is executed as follows. 

The Engine throws "Responder Missing" if the stack is 
10 cleared, since the responder was to have been on top of 
the stack. The Engine throws "Feature Unavailable" if 
20 either the responder lacks the operation the identifier 

denotes or the requester lacks access to the operation. 
Otherwise, the Engine selects and performs a method for 
15 the operation as described in the sections below. 



Qualified I dent i f ier 

A qualified identifier for an operation is executed 
in the same way as is an identifier which is not a 
qualified identifier, for that operation, with these 

20 exceptions. 

Before method selection, the Engine throws 
"Escalation Invalid" if the requester is not the 
responder. Otherwise, the Engine requests operation 
"getClass", its argument being an identifier whose text is 

25 the qualifier, and throws "Escalation Invalid" if the 
operation's result is neither the class to which the 
current method is native nor one of its immediate 
implementation superclasses. 

During method selection, the Engine confines itself 

30 to the result of operation "getClass" and its 

implementation superclasses. The operation has been 
escalated . 
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2.3.10 Method Selection 

The Engine selects fcr an operation the first method 
it finds by searching the following four locations in the 
order in which they are listed here: 
5 • If the responder is a class, its class methods. 

• If the responder is a class, the class methods of its 
implementation superclasses, which are investigated 
in canonical order. 

• The instance methods of the responder' s class. 
0 • The instance methods of the implementation 

superclasses of the responder' s class, which are 

investigated in canonical order. 

If a method escalates the operation, the Engine 
attempts to select another, resuming its search after the 
5 class to which the method it selected previously is 
native. If it finds no method, the Engine throws 
"Escalation Invalid" . 

2-3.11 Method Performance 

The Engine performs, as follows, the method it 
0 selects for an operation. 

Arci-. -ents Fixed in Number 

If the operation requires a fixed number of 
arguments, the Engine throws "Argument Missing" if the 
stack's length is less than one plus that number, and 
5 throws "Argument Invalid" if an argument violates the 
argument's constraint. 

Arguments Variable in Number 

If the operation requires a variable number of 
arguments, the Engine throws "Mark Missing" if the stack 
0 does not include a mark, and throws "Argument Invalid" if 
an argument violates the argument's constraint. 

Performance 
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The Engine pops the responder from the stack, creates 
a frame for the method's performance, performs the method, 
and discards the frame. 

The following actions surround the method's 
5 performance. The Engine offers the operation's arguments, 
moving them from the requester's stack to the responder' s. 
If the number of arguments is variable, the mark is 
offered in this way as well. The Engine accepts the offer 
of the operation's result, if there is to be one, moving 
it from the responder' s stack to the requester's. 

Success 

If the method succeeds and the operation was to 
produce a result, the Engine does the following. If no 
result was produced, the Engine throws "Result Missing". 
15 If the result does not satisfy the result's constraint, 
the Engine throws "Result Invalid". Either exception is 
handled as described below. 

Failure 

If the method fails and the operation was not to 
0 threw the exception it actually threw, the Engine 

substitutes "Unexpected Exception" for that exception. 

2 . 4 Process Model 

The Instruction Set realizes the "process model" this 
section defines. 

5 2.4.1 Processes 

A "process" is a named, autonomous computation. It 
constitutes the Instruction Set's provision for 
multi -tasking . 

Note: A process often represents something in the real 

3 world, e.g., a person, whose objectives the 

process seeks to further in the Network. 
Mote: There are two kinds of process, agent and place. 
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Interaction 

If cne process has a reference to another, the two 
can interact in the same way as can any two objects: by 
means of their respective features. Each argument or 
5 result of such a feature enables one process to convey to 
the other either a reference to, or .a copy of, an object. 

2,4.2 Phases 

A process goes through phases. The Engine requests 
and the then potential process successfully performs 
0 operation "initialize". The Engine requests and the 
process successfully performs operation "live", a nil 
being supplied as the operation's argument. The Engine 
requests and the process performs operation "finalize". 

Exceptions 

5 The normal progression of phases described above may 

be interrupted. If operation "initialize" throws an 
exception, the Engine terminates the process. If 
operation "live" throws an exception, the Engine either 
restarts the process by requesting operation "live" again, 

0 the exception being supplied as the operation's argument, 
if the permit the process holds allows this, or requests 
operation "finalize" otherwise. If operation "finalize" 
throws an exception, the Engine terminates the process. 

If the process exhausts its native or local permit in 

5 any phase above, the situation is as if the process had 
thrown "Permit Exhausted". 

2.4.3 Threads 

Every process gives rise to an independent thread of 
execution which comprises, at any moment, the frames of 
0 the methods being performed on the process' initiative. 
The first such method is the one the process itself 
provides for operation "live" the second the one an object 
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provides for a feature that the method for operation 
"live" requests of that object, and so on, recursively. 

Scheduling 

The Engine schedules all execution threads that are 
5 not blocked, e.g., waiting until a certain time, switching 
preemptively between them as necessitated by their 
priorities. All else being equal, the Engine favors 
neither the processes of one authority over those of 
another, the processes of one brand over chose of another, 
10 nor one process over another of the same priority.' 

Interruption 

When the Engine itself requests a feature of an 
object, i.e., a system feature, the feature's method is 
performed as part of the thread of the object's owner. 
15 The owner, in effect, is interrupted for that purpose. 



2.4.4 Resources 
30 A "resource" is something about which certain 

guarantees can be made to a process throughout its 
performance of a particular procedure. The Engine may 
20 delay the process until it can make the guarantees. 
35 Note: Resources enable the definition of critical 

conditional regions. 
Note: a resource is often a proxy for a physical 

resource (as exemplified below) . 
40 25 Note : In an electronic mail system, e.g., an agent 

serving as a mailbox might include among its 
properties a database of delivered messages and 
45 a resource representing the database. The agent 

would obtain exclusive use of the resource 
30 before beginning the task of adding a newly 

delivered message to the database, thereby 
50 ensuring the database's integrity in the face of 

concurrent deliveries. 
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70 



15 



20 



25 



Need 

Because one process can convey a reference to an 
object to another process, every object must be prepared 
for the methods native to or inherited by its class to be 
5 performed concurrently by those processes. Resources 
enable objects to make such preparations. 

Resources are used to ensure that sequences of 
operations are carried out atomically. For one operation, 
such precautions generally are not required because the 
10 Engine performs atomically all predefined operations 
except operations "wait", "meet" and any predefined 
operation that performs a procedure supplied as either the 
responder, e.g., operation "do", or an argument, e.g., 
operation "restrict" . 
15 Note : The Engine performs operations "go" and "send" 

atomically . 

Exclusive vs Shared 

A process can be guaranteed either shared or 
exclusive use of a resource. At any time, either no 
20 processes have use of the resource, one process has 
"exclusive" use of it, or one or more processes have 
"shared" use of it. 

Condition 

A process can be guaranteed that a resource is among 
25 one or more conditions identified when the request is 

made. At any time, a resource has a "condition" which is 
among one or more conditions defined when the resource was 
created. Denoted by an identifier, a resource's condition 
can be examined only by a process with use, shared or 
30 exclusive, of the resource, and can be modified only by a 
process with exclusive use of the resource. 

50 2.4.5 Permits 
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A "permit" grants capabilities to a process, its 
"subject". The capabilities represented by the bulk of 
the Instruction Set, e.g., the Instruction Set's 
arithmetic operations, are implicitly granted to each 
5 process. Other capabilities are explicitly granted to 
particular processes by means of the permits assigned to 
these processes. 

Note: The principal purpose of permits is, as far as 

possible, to prevent processes from consuming 

L0 computer and communication resources in 

unintended amounts. This benefits users, who 
create the processes and may have to pay for 
them, but also providers, who must provide the 
resources that the processes consume. 

-5 Note : The resources mentioned above are not to be 

confused with members of class "Resource". 
There is no necessary connection between the 
two. 

Capabilities 

0 A permit grants capabilities in certain defined 

dimensions and amounts. 

A permit can grant a process a certain age, size, 
charges, priority, or authenticity. The charges to which 
a permit entitles its subject is called the subject's 

5 "allowance". An amount in any cf these dimensions is an 
integer. Age is measured in seconds, size in octets, and 
charges in "teleciicks" . Priority increases with its 
integer value. Authenticity is region-specific. 

A permit can grant a process the right to transport 

0 itself (attribute "canGo" of the permit), create and 
transport clones of itself (attribute "canSend"}, create 
other peer processes (attribute "canCreate" ) , set the 
permits of selected processes so as to decrease (attribute 
"canDeny") or increase (attribute "canGrant") their 

5 capabilities, increase the actual charges of other 
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processes (attribute "canCharge") , or be restarted if 
terminated (attribute "canRestart " ) . An amount in any of 
these dimensions is a boolean, where a boolean whose value 
is "true" grants the right in question. 
5 Each dimension in which a permit can grant 

capabilities is represented by an attribute of the permit. 
If normally an integer, the attribute can be a nil 
instead, in which case the capability is granted in 
unlimited amount. 
10 None : The charge, in teieclicks, for a service 

rendered to a process, whether by an Engine or 
by another process, can vary from place to 
place, from time to time, or both. The charges 
for some services, e.g., space, can be assessed 
15 per unit time . 

Status 

A process' "status" identifies the process' exercised 
capabilities. The status of a process is the process' 
effective permit", which is described below, except that 
20 the permit's "age", "charges", "extent", and "priority" 
attributes are the process' actual age, charges, size, and 
priority, respectively. 

Effective Permit 

A process' "effective permit" identifies the process' 
25 allowed capabilities. At any time and place, this permit 
is the intersection of the process' native, regional, and 
local permits and any temporary permits in force. For 
this purpose, however, the native permit's "authenticity" 
attribute is considered a nil unless the process is in the 
30 region in which the process was created. 

The "intersection" of two permits is itself a permit, 
each of whose native attributes, a,,, is the intersection of 
the like-named attributes, A, and A : , of the two permits in 
question. More specifically, Ao is either A t , if A : is a 
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10 



15 



20 



a nil; A 2 , if A x is a nil; or the minimum of A 1 and A 2 , 
otherwise. The Engine notifies a process, e.g., by use of 
operation "restricted" which is described below, if any of 
the process' permits, once set, is set again. 
5 A process "violates" its permit by attempting to 

exercise a capability in an amount greater than is granted 
the process by the process' effective permit. Violating 
one's permit without also exhausting the permit provokes 
an exception. 

10 A process "exhausts" its permit by allowing the 

process' actual age, charges, or size to reach the age, 
charges, or size, respectively, that the process' 
effective permit would grant the process if none of the 
process' temporary permits were in force. Exhausting 
15 one's permit initiates one's termination. 

25 Native Permit 

A process' "native permit" identifies the 
capabilities granted to the process by the creator of the 
process. One process, the parent, sets this permit when 
20 the parent creates another process, the child. A peer 
process can decrease but not increase capabilities, if so 
empowered by the peer's own effective permit (attribute 
"canDeny") . 

Capabilities are transferred between processes but 
25 not created. The parent or peer cannot grant the child a 
capability, "X", which the parent or peer does not have 
itself. Let "P" be the amount of "X" granted the parent 
or peer by its effective permit. Let "C" be the amount of 
"X" granted the child by the child's native permit. "C M 
30 shall not exceed "P". 
45 The charges capability ("X") is conserved. Let "A" 

be the amount of the parent's or peer's actual charges 
beforehand. »C» shall not exceed "P-A". The amount of 
the parent's or peer's actual charges afterwards is "A+C" . 

50 
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Regional Permit 

A process' "regional permit" identifies the 
capabilities granted to the process by the region that 
includes the place the process occupies. A place of the 

5 region's authority can set the permit when the process 
enters the region and at any time thereafter, if so 
empowered by the place's own effective permit (attributes 
"canDeny" and "canGrant"). If a child enters using 
operation "new", not operation "go" or "send", however, 

0 the child's initial regional permit is made the parent's 
current regional permit. 

Local Permit 

A process' "local permit" identifies the capabilities 
granted to the process by the place the process occupies. 
5 The place \;an set the permit when the process enters and 
at any time thereafter, if so empowered by the place's own 
effective permit (attributes "canDeny" and "canGrant"). 

When entering a place using a ticket, an agent 
requests certain capabilities of the place. The place, 
0 however, decides what capabilities the agent shall have. 
The place can allow the agent to enter with a local permit 
more or less capable than the one the agent requested. In 
the latter case, however, the trip fails, i.e., operation 
"go" or "send" throws an exception even though the agent 
5 has arrived. 

When entering a place by being created there, a 
process receives as the process' initial local permit one 
created with no initialization parameters. 

Temporary Permit- s 
0 A process' zero or more "temporary permits" identify 

the capabilities the process grants itself temporarily. 
Each is put in force using operation "restrict" or 
"sponsor" for a specified procedure's performance. Such 
procedures can be nested. 
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Whenever the Engine requests a system feature, the 
responder's owner implicitly sponsors the operation's 
method using a temporary permit created with no 
initialization parameters. In this way, charges accrue to 
5 the owner. 

Note: Using a temporary permit, a process can hold in 

reserve a portion of the process' allowed age, 
charges, or size. If the process exhausts the 
bulk of this commodity, the process can use the 
0 portion held in reserve to take emergency 

action. 

2.4.6 Ownership 

Every object that is not itself a process is "owned" 
by one. A process and the objects it owns are the 
5 "artifacts" of that process. 

Note: Ownership is not to be confused with authority. 

Object Creation 

Every object, ultimately, is created by passing by 
copy between methods either an argument of a feature or a 
0 feature's result. The new object--the copy that is 

passed- -is owned by either the cbject to whose method the 
copy is conveyed, if that object is a process, or that 
object's owner, otherwise. 

Object Pest rue t ion 
5 When a process is destroyed, all of its artifacts are 

destroyed, and all remaining references to them voided. 

Object Sharing 

A place's artifacts can refer to its immediate 
superplace's artifacts, which constitutes a first realm 
0 and its own artifacts and those of its immediate 

subplaces, which collectively constitute a second realm, 
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but the Engine voids a reference passed between the two 
realms . 

Note : Thus fire walls are erected between places. 

2.4.7 Cloning 
5 A process can be given the capability to clone 

itself. A clone is one process that begins as a copy of 
another process, i.e., the "original", with these 
except ions . 

The clone's identity, but not its authority, differs 
0 from the original's. 

The clone's native perrr.it, which is also its local 
permit, is that given when the clone is created. Any 
temporary permits pending in the original, i . e . , as a 
result of operation "restrict", are made more restrictive 
5 within the clone to the extent that the clone's native 
permit requires this. 

Wherever the original refers to itself or an object 
the original owns, the clone refers to itself or its own 
copy of that object, respectively. Wherever the original 
0 refers to an artifact of a third process, the clone has a 
voided reference. 

If the original, and thus the clone, are contacted 
objects, the clone's "contacts" attribute is cleared. 

2.4.3 Branding 

5 A region brands every process within it. 

A "brand" is a distinguishing mark born by zero or 
more processes in a region. When an agent enters a 
region, the region gives the agent a new brand. When one 
process within the region creates another, the latter 

0 bears the brand of the former. Thus a brand denotes a 
process, e.g., an agent, that entered the region and all 
of the processes created there by the former process. 
Note: Brands enable tracking mechanisms, which are not 

themselves in the Instruction Set. 
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2.4.9 Contacts 

A "contact" represents and documents for one process, 
the "observer", its interaction with a second process, the 
"subject". A "contacted" process receives help from the 
5 Engine in maintaining its set cf contacts. 

2.4.10 Isolation 

A process is isolated under various circumstances, 
e.g., upon either parting from all its acquaintances using 
operation "partAll" , initiating a trip, or terminating. 
0 To "isolate" a process is to void each reference to 

an artifact of the process that is held by an artifact of 
any other process, and to void each reference that an 
artifact of the process holds to an artifact of any other 
process. There are two exceptions. First, the place that 
5 the process occupies retains its references to the 

process, but not to the objects the process owns. Second, 
the process can continue to refer to the place the process 
occupies . 

2.4.11 Terninat ion 
A prccess is terminated in a way that enables the 

methods whose frames are involved in the process' thread 
of execution to conclude gracefully. 

Let (i) A, B, and C be processes, (ii) an artifact of 
A request a feature of an artifact of B , (iii) an artifact 
of B in turn request a feature of an artifact of C, and 
(iv) A exhaust its native or local permit. The Engine 
then terminates A as follows. 

Unless A, B, and C are one and the same, the Engine 
throws "Permit Exhausted", returning control to the method 
cf A, B, or C that most recently prepared, using operation 
"catch" for that exception. The method is resumed, but 
with A holding the local permit of A, B, or C, whichever 
is either the object with which the method is associated 
or that object's owner. When the method finishes, either 



123 



EP 0 634 719 A2 



succeeding or failing, the Engine reinstates the exhausted 
permit of A, re- initiating the above termination 
algorithm . 

After doing the above, the Engine (i) halts A, 
5 (ii) isolates A, (iii) presents A for diagnostic 

examination if the GAM policy in force so requires, and 
(iv) destroys A. 

2 . 5 Network Model 

The Instruction Set realizes the "network model" this 
0 section defines. 



2.5.1 Aaents 

An "agent" is a process that can move from place to 
place . 

An agent can transport itself to a particular 
5 destination via operation "go" or commission one or more 
clones to travel several destinations concurrently via 
operation "send" . 



Note: The "go" and "send" operations of the 

Instruction Set are its most distinctive and 
powerful aspect. In most network architectures, 
all processes are stationary and communicate by 
exchanging messages. m this one, some 
processes are stationary, but others are mobile, 
the former communicating by means of the latter. 
This is a paradigm shift. 

2.5.2 Places 

A "place" is a process that is the locale for zero or 
more other processes, each of which can refer to and thus 
interact with the place. 

Note: Places represent the Instruction Set's only 

example of action at a distance. Places 
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interact by means of agents which travel between 
them . 

Engine Place vs Virtual Places 

There are two kinds of place. Every Engine sustains 
5 one "engine place", representing the Engine itself, and 
zero or more "virtual" places. 

Subplace vs Suoerplace 

Any place except an engine place can occupy another 
place. If cne place occupies another, either directly or 
0 indirectly, the former is a "subplace" of the latter, and 
the latter is a " superplace " of the former. If one place 
occupies another directly, the former is an "immediate 
subplace" of the latter, and the latter is the "immediate 
superplace" of the former. 

5 Place Hierarchy 

The places an Engine sustains can be arranged as the 
nodes of a tree, the "place hierarchy", in which the nodes 
represent places, the arcs between nodes the occupation 
relationship between the places the nodes represent. 
0 Note : The tree's roct represents the engine place, the 

other nodes virtual places. 

2.5.3 Trips 

A "crip" is an agent's move from one place, the 
trip's "origin", to another cr the same place, the trip's 
5 "destination". A trip can fail, leaving the agent either 
at its origin or in a "transit" place, neither its origin 
nor its destination. 

Note: A trip may take a long time because sometimes 

the trip entails transporting the agent by means 
0 of physical, not just logical, communication 

media . 
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.0 



Operation "q o" vs Operation "send" 

An agent can travel to a single destination itself 
via operation "go" or commission one or more clones to 
travel to several destinations concurrently via operation 
5 "send". 

Note: The "send" operation transports a single 

representation cf the agent to any particular 
Engine, even if several clones are being sent to 
places that that Engine sustains. Further 
savings, e.g., of space in memory of a computer, 
can be achieved at that Engine. 



Restrictions 

The operation "go" or "send" shall be requested only 
by either the procedure of a method native to a subclass 
5 of class "Agent", or a procedure chat is an item of such a 
procedure, recursively. The Engine throws "State 
Improper" otherwise . 

2 ■ 5 - 4 Tickets 

A "ticket" describes an intended trip from the 
0 viewpoint of the agent taking the trip. The ticket's main 
purpose is to identify the trip's destination. 

Composition 

A ticket comprises a telename and a teleaddress of 
the destination, a citation to a class of which the 
5 destination is a member, the local permit the agent 
requires at the destination, the time interval within 
which the trip should be accomplished ideally, and the 
time interval within which the trip shall succeed or fail 
under any circumstances. 
3 Note: Defining the desired time interval helps the 

Network decide how to distribute its 
communication resources among traveling agents. 
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Note : The effect of defining the maximum time 

interval, which is permitted as a programming 
convenience, also can be achieved by means of 
operation "restrict" . 

5 Satisfaction 

A ticket is satisfied by any place of the identified 
name, address, and class that agrees to the agent's 
arrival within the maximum time interval. 

If no place satisfies the ticket, the Network rejects 
l0 the ticket. 

If a set of two or mere places satisfy the ticket, 
the Network attempts a trip to successive members of the 
set until one agrees to the agent's arrival or all places 
that the Network approaches reject the agent's arrival. 
.5 The order in which the Network approaches the set members, 
to what extent the Network's coverage of the set is 
complete, and whether the Network approaches places that 
join the set after the ticket is presented are undefined. 

2.5.5 Meet incs 

0 A "meeting" is an opportunity for two occupants of 

the same place, which are both petitioned objects and thus 
agents, tc interact with one another. The requesting 
agent is the "petitioner", the responding agent the 
"pet itionee" . 

5 Meet ina 

One agent can ask to "meet" another via operation 
"meet". The Engine -- not the petitioner -- requests 
operation "meeting" of the petitionee, supplying as an 
argument a contact for the petitioner. Meeting hinges 
0 upon that operation's outcome. 

The Engine gives the two agents references to one 
another iff the meeting is consummated by the success of 
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operation "meeting" . While they are meeting, the two 
agents are said to be "acquaintances" of one another. 

The Engine dees not serialize meetings with an agent 
That the agent is performing operation "meeting" already 
5 does not deter the Engine from requesting performance of 
operation "meeting" again. T:.e agent must provide, e.g., 
by means of a resource, any meeting serialization the 
agent requires. 



Part ing 

0 Either of the two agents can "part" from one or all 

of its acquaintances, via operation "part" or "part All", 
respectively. The Engine not the agent -- requests 
operation "parting" of the agent's acquaintance or 
acquaintances. The Engine supplies as an argument the 

5 contact the Engine before supplied as either an argument 
of operation "meeting" or the result of operation "meet". 
Unlike meeting, a successful parting does not hinge upon 
the outcome of operation "parting"; parting occurs 
immediatel y and uncondit ionally . 

0 The Engine voids each agent's references to the 

artifacts of the other. 

The Engine does not serialize partings from an agent 
That the agent is performing operation "parting" already 
does noc deter the Engine from requesting performance of 
operation "parting" again. The agent must provide, e.g., 
by means of a resource, any parting serialization the 
agent requires . 

If both agents ask to part from one another, whether 
the Engine requests operation "parting" cf either is 
undefined. 



Restrictions 

The operation "meet", "part", or "partAll" shall be 
requested only by either the procedure of a method native 
to a subclass of class "Agent", or a procedure that is an 
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item of such a procedure, recursively. The Engine throws 
"State Improper" otherwise. 

2 -5.6 Petitions 

A "petition" describes 
5 viewpoint of the petitioner 
identify the petitionee. 

Composition 

A petition comprises a telename of the petitionee, a 
citation to a class of which the petitionee is a member, 
L0 and the time interval within which the meeting attempt 
shall succeed or fail under any circumstances. 
Note; The effect of defining the maximum time 

interval, which is permitted as a programming 
convenience, also can be achieved by means of 
.5 operation "restrict". 

Sat isf act ion 

A petition is satisfied by any petitioned object of 
the identified name and class that agrees to the meeting 
within the maximum time interval. The petitionee must be 

0 an occupant of the same place as the petitioner at seme 
point within the maximum time interval, but not 
necessarily at its start. 

If no petitioned object satisfies the petition, the 
Engine rejects the petition. 

5 If a set of two or more petitioned objects satisfy 

the petition, the Engine attempts a meeting with 
successive members of the set until one agrees to the 
meeting or all petitioned objects that the Engine 
approaches reject the meeting. The order in which the 

0 Engine approaches the set members, to what extent the 
Engine's coverage of the set is complete, and whether the 
Engine approaches agents that join the set after the 
petition is presented are undefined. 



an intended meeting from the 
Its main purpose is to 
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2.5.7 Occupation 

The occupants of a place can change ever time. 

Entry 

A process can "enter", and thus occupy, a place in 
5 either cf two ways. An agent can arrive at the place as a 

consequence of a trip, or one process at the place already 

can create another process of the place. In either case, 

the Engine -- not the arriving agent or the creating 

process requests operation "entering" of the place. A 
0 contact for the arriving agent or the created process is 

supplied as an argument of operation "entering" . 

Successful entry hinges upon the operation's outcome. 

The Engine gives the place and the process entering 

the place references to one another iff the entry is 
5 consummated, i.e., by the success of operation "entering". 

While occupying the place, the process is said to be an 

"occupant:" of the place. 

The Engine does not serialize entries to a place. 

That the place is performing operation "entering" already 
0 does not deter the Engine from requesting operation 

"entering" again. The place must provide any entry 

serialization the place requires. 

Note: Operation "entering" is involved even if a 

trip's origin and destination are the same. 

5 Exit 

A process can "exit", and thus no longer occupy, a 
place in either of two ways. An agent can depart from the 
place as a consequence of a trip, or one process at the 
place can destroy itself or another process at the place. 
0 In either case, the Engine not the departing agent or 
the destroying process -- requests operation "exiting" of 
the place. The same contact supplied as an argument: of 
operation "entering" is supplied as an argument of 
operation "exiting". Unlike entry, a successful exit does 
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not hinge upon the latter operation's outcome; the exit 
already occurred. 

The Engine voids the references of the place and the 
process exiting it to the artifacts of one another. The 
5 Engine, furthermore, isolates the process. 

The Engine does not serialize exits from a place. 
That the place is performing operation "exiting" already 
does not deter the Engine from requesting operation 
"exiting" again. The place must provide any exit 
0 serialization the place requires. 

Note : Operation "exiting" is involved even if a trip's 

origin and destination are the same. 

2.5.8 Contacts 

The Engine offers places and agents assistance 
5 maintaining their contacts with their occupants and 
acquaintances, respectively. 

Occupants 

If a place is also a contacted object; the Engine 
maintains the place's contacts attribute in such a way 
0 that the attribute always includes the place's current 
occupants and none of its previous ones . 

The Engine includes in or excludes from the place's 
attribute a contact for a process at the moment the 
process enters or exits the place, respectively. 

5 Acquaintances 

If a petitioned object is also a contacted object, 
the Engine maintains its contacts attribute in such a way 
that the attribute always includes the object's current 
acquaintances and none of its previous ones. 

0 The Engine includes in the petitioner's or 

petitionee's attribute a contact for the petitionee or the 
petitioner when operation "meet" or "meeting" succeeds, 
respectively . 
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The Engine excludes the contacts from the attributes 
of both the petitioner and the petitionee when either 
process requests operation "part" or "partAll" . 

2.5.9 Citations 

Within the Network, objects of certain classes are 
denoted by citations. 

Citations 

A "citation" identifies zero or more cited objects by 
title and, optionally, author, edition, or both author and 
edition. A citation identifies the author by the author's 
authority and, optionally, -he author's identity. If a 
citation leaves any of the three characteristics 
undefined, the citation denotes all cited objects with the 
characteristics citation does define. 

Author 

An "author 11 is the process that creates a cited 
object. Thus an author is identified by a telename. The 
authors of all editions of a title are peers. 

Title 

A "title" is a series of cited objects, one asserted 
zz be backward or forward compatible with another. A 
title is denoted by an identifier, which is interpreted 
relative to the common authority of the title's authors. 

Edition 

An "edition" is any of the cited objects in a title. 
An edition is denoted by two integers. One, interpreted 
relative to the title, denotes a major edition. The 
other, interpreted relative to the first, denotes a minor 
edit ion . 
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Note : A title's first major or minor edition is 

usually assigned che number one or zero, 
respectively . 



Assigned Citations 

5 An "assigned citation" denotes one cited object by 

author, title, and edition, identifying the author by both 
its authority and its identity. The assigned citation 
thereby distinguishes che cited object from all ether 
cited objects, and thus from the others in the assigned 

.0 citation's own title. See discussion of telenames below. 

Compatibility 

One cited object, 0 : , is "backward compatible" with 
another, O, , iff 0 : can be created by making to O, only 
changes of the kinds prescribed by a class of which both 
5 cited objects are members, the kinds of change chosen to 
ensure that a program written to process O t can process 
as well. Under the same conditions, 0, is "forward 
compatible" with 0 2 . 

2.5.10 Telenames 
0 Within the Network, objects of certain classes are 

denoted by telenames. 



Telenames 

A "telename" identifies zero (if the telename is 
invalid) or more named objects by their authority and, 
5 optionally, their identity. If the telename leaves their 
identity undefined, the telename denotes all named objects 
of the identified authority. 



Authority 

A named object's "authority" is the entity, e.g., the 
0 person or the organization, responsible for the object. 
An authority is identified by an octet string, which 
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distinguishes the authority from all others in the 
Network . 

5 

Two telenames are "peers" iff they identify the same 
authority . 

10 5 Note : Authorities are created administratively , not 

programmatically . Identities, however, are 
created in both ways. 
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Identity 

A named object's "identity" is the named object 
10 itself. An identity, like an authority, is identified by 
an octet string, which, even by itself, distinguishes the 
identity from all others in the Network. 

Note: The octet string denoting an authority or an 

identity may have no meaning to a human being. 

15 The Instruction Set does not define how the 

octet string is assigned. 



Assigned Telenames 

An "assigned telename" denotes exactly one named 
object by authority and identity. 



20 2.5.11 Teleaddresses 

Within the Network, places are located by 
teleaddresses . 

The "Network" comprises all engine places and is 
divided into one or more regions. A "region" is one or 
25 more engine places operated, or provided, by a particular 
authority. 

Teleaddresses 
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A " teleaddress" identifies zero {if the teleaddress 
is invalid) or more places by their region and, 
optionally, their location. If the teleaddress leaves 
their location undefined, the teleaddress denotes all 
5 places in the identified region. 

Region 

A place's "region" is the region that contains the 
place. A region is identified in the sane manner as is an 
authority (see discussion of telenames above) , and thus by 
10 an octet string, which distinguishes the region from all 
others in the Network. 



Location 

A place's "location" is any characteristic of the 
place selected for that purpose by the authority of the 
25 15 place's region. A location is identified by means of a 
string, which distinguishes the location from all others 
in the region. 

Two places in a region can have the same location. 
Note: The location of a place might be, e.g., the 

2C computer system sustaining it. 

Mote: The string denoting a location can, but need 

not, have meaning to a human being. The 
Instruction Set does not define how the string 
is assigned, and the manner of assignment 
25 varies, in general, from one region to another. 



Routing Advice 

A teleaddress can, but need not, offer advice on the 
routing of agents to the places the teleaddress denotes. 
The teleaddress does this by suggesting one or more 
30 regions through which such agents may be routed. In the 
absence of such "routing advice", the Network may be 
unable to transport agents to those places, e.g., if those 
places are far removed from an agent's source. 
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Assigned Teleaddresses 

An "assigned teleaddress" identifies one. or mere 
places -- because several places can have the same 
location -- by their region and their location within the 
5 region. 

2.5.12 Interchange 

An "interchanged object" is an immutable object for 
which the Network can, but need not, substitute an 
equivalent object, which is found, e.g., at the 
10 destination, whenever the object's owner takes a trip, on 
which the object must accompany it, provided the 
interchanged object has a digest. Digests are described 
below . 

Note: Interchanged objects improve the performance of 

15 operation "go" and "send" by sometimes allowing 

an Engine to avoid physically transporting the 
interchanged objects by substituting for them 
equivalent objects found, e.g., at the 
destination. 

20 Note: Classes and packages are interchanged objects. 

Digests 

An interchanged object is deemed equivalent to any 
other instance of the object's class whose digest equals 
that of the interchanged object. A "digest" is any 
25 object, other than a nil, that is suited to this purpose. 
For example, a digest can be a mathematical hash of a 
canonical binary representation of the interchanged 
object . 

Note: An interchanged object improves the performance 

30 of operations "go" and "send" only if the object 

is larger than its digest. 

2 - 6 Timekeeping Model 
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The Instruction Set realizes the "timekeeping model" 
this section defines. 

One can keep time in two ways. A time or a calendar 
time alike identifies a date and time, but the two differ 
5 in ether respects. 

Note : Times can be converted to calendar times, and 

conversely. 

Note : The Engine can internally represent times more 

compactly than it does calendar times. Thus 
0 times are better, in general, for storing and 

transporting dates and times. 



2.6.1 Time 

A "time" identifies a date and time of day to the 
precision of one second using Coordinated Universal Time 
5 (UTC) . A time also identifies the time zone in which the 
time was measured and to what extent, if any, Daylight 
Savings Time (VST) was in effect at that time in that 
place . 

Note : UTC is effectively what was formerly known as 

G Greenwich Mean Time (GMT) . 

2.6.2 Calendar Time 

A "calendar time" has all the characteristics of a 
time, and others. In particular, a calendar time exposes 
to examination and modification the hour of the day, the 

5 minute of that hour, and the second of that minute. It 
exposes the year in the Gregorian calendar, the month of 
that year, and the day of that month. It exposes the days 
of the week and year. It also exposes the time zone's 
permanent offset in minutes from UTC and its seasonal 

0 offset in minutes from its permanent one. The time is DST 
if the latter offset is non-zero. 



Normality 
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A calendar time makes each facet of the date and time 
of day accessible as an integer that is normally in a 
prescribed range. The hours are numbered in the range of 
[0, 24), the minutes in the range of [0, 60), and the 

5 seconds in the range of [0, 60] . seconds are numbered in 
the range of [0, 50], i.e., 61 possible values, to 
accommodate leap seconds. The year 1993, e.g., is denoted 
by the integer 1993, the months are numbered in the range 
[1, 12] , and the days are numbered in the range [1, 31] 

0 The days of the week are numbered 1, 2, 3, 4, 5, 6 or 7, 
which represent Sunday, Monday, Tuesday, Wednesday, 
Thursday, Friday, and Saturday, respectively. The days of 
the year are numbered in [l y 366] . The permanent and 
seasonal offsets are both numbered in [-720, 720]. 

5 Note : Positive numbers denote years A.D., and negative 

ones denote years B.C. 

Abnormality 

A calendar time may have facets whose integer values 
lie outside their normal ranges. It might identify the 

C date, e.g., as September 32, by which October 2 is meant. 
Such abnormal values may result from manipulating a 
calendar time in useful ways, e.g., adding two to the day 
of the month, but must be eliminated before the calendar 
time can be considered correct. A calendar time is made 

5 correct in this sense by a process of normalization. 

Normalization 

A calendar time is "normalized" in the following 
steps, the first of which takes into account the fact that 
any facet of a calendar time can be a nil: 

0 Defaults 

• The hour, minute, or second, if nil, is made zero. 
The year, month, or day, if nil, is made one. The 
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permanent or seasonal offset, if nil, is made that of 
a normalized calendar time denoting the current time. 

Offsets 

• The permanent and seasonal offsets are replaced by 
the result of transposing into [-720, 720] the 
remainders left by dividing the offsets by 24*60, 
i.e., by the integer value 1440. 

Time 

• The second is placed in normal range by repeatedly 
adding or subtracting 60, each time respectively 
subtracting or adding one to the minute. The minute 
is placed in normal range by repeatedly adding or 
subtracting 60, each time respectively subtracting or 
adding one to the hour. The hour is placed in normal 
range by repeatedly adding or subtracting 24, each 
time respectively subtracting or adding one to the 
day . 

Date 

• The month is placed in normal range by repeatedly 
adding or subtracting 12, each time respectively 
subtracting or adding one to the year. The day is 
placed in [1, K] by adding or subtracting K, 
respectively subtracting or adding one to the month. 
K is the number of days in the subject month in the 
subject year. If one addition or subtraction does 
not place the day in the required interval, this 
entire step is taken again. In other words, the 
month is adjusted as described above before adjusting 
the day again. 

Days 

• The days of the week and year are set correctly. 
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Localize vs Globalize 

A calendar time can be modified to reflect another 
permanent or seasonal offset without altering the absolute 
point in time it identifies. A calendar time is 
5 "localized" if its offsets are made those of the current 
place. A calendar time is "globalized" if its offsets are 
made these of UTC. 

2 . 7 Pattern Matching Model 

The Instruction Set realizes the "pattern matching 
0 model" this section defines. 

2.7.1 Patterns 

A "pattern" is a means for lexically analyzing a 
string. The pattern's "text", itself a string, prescribes 
the criterion by which a string matches the pattern. 

5 A pattern's text is a series of tokens obeying the 

syntactic, and accompanying semantic, rules below. Given 
in BNF (Backus -Naur or Backus Normal Form) , the rules 
surround optional tokens by brackets ( " [ " and "]"). They 
surround vertical bar <"!"), left bracket < M ["), and right 

0 bracket ("]"• by quotation marks ( "" ) to distinguish 
their use, in accord with BNF, in describing the text of 
any pattern, on the cne hand, from their possible use as 
metacharacters in a particular text, on the other. 

Each token in a pattern's text is zero cr more 

5 characters. The text is obtained by concatenating the 
tokens, and thus the characters. 

2.7.2 Structure 
Pattern 

A pattern, i.e., its text, obeys this rule: 
D Pattern :: = Alternative [ " | Pattern] 
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A string matches a pattern iff it matches any of its 
alternatives . 

Alternat ive 

An alternative cbeys these rules: 

Alternative ::= [*] Components [$] 
Components ::= Component [Components] 

A string matches an alternative iff successive substrings, 
with no gaps between them, match successive components of 
the alternative. If the alternative begins with a caret 

) or ends with a dollar sign ("$"), the series of 
substrings must begin or end at the string's beginning or 
end, respectively. 

Component 

A component obeys this rule: 
Component : := Icem [* j + j ?] 

A string matches a component iff it either comprises zero 
cr more substrings, each matching the item, if an asterisk 
("*") appears; comprises one or more such substrings, if a 
plus sign ( " +") appears; either matches the item or is 
cleared, if a question mark ("?") appears; or matches the 
item, otherwise. 



An item obeys this rule: 

Item : : = ; Pattern ) | 

" C CharacterClass " ] " j 
Character 
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A string matches an item iff it matches either the 
pattern, the character class, or the character, whichever 
the item prescribes. 

CharacterClass 
5 A character class cbeys this rule: 

CharacterClass ::= [ A ] Characterl terns 

A string matches a character class iff it matches the lis 
of character items iff the caret (*) is not present: 

Characterltems 
0 A list of character items cbeys these rules: 

Characterltems ::= Characterl tern [Characterl terns] 
Characterltem ::= CharacterRange | Character 

A string matches a list of character items iff successive 
substrings of the string, with no gaps between them, mate; 
5 successive character items in the list. The series of 
substrings must begin at the string's beginning and end at 
the string's end. 

CharacterRange 

A character range obeys this rule: 

0 CharacterRange : : - Character - Character 

A string matches a character range iff the string 
comprises one character after or equal to the first 
character and before or equal to the second. 
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Character 

A character obeys this rule : 

Character : : = . j \ metacharacter j character 

A string matches a character iff the string comprises 
5 either any one character, if a period (".") is present; 
the metacharacter, if a reverse slash ("\" ) is present; or 
the character, otherwise. 

Note : Thus the special meaning of a metacharacter is 

avoided if a reverse slash ("\") immediately 
C precedes the metacharacter. 

2.7.3 Other Non - terminals 
character 

Any instance of class "Character" other than a 
metacharacter . 

5 metacharacter 

A metacharacter. 

2.7.4 Metacharacters 

A pattern's text can include metacharacters. A 
metacharacter has a special meaning which is among the 
0 semantic rules that govern the text. The metacharacters 
are the characters in Table A. 5 and those, e.g., backspace 
tabulated for a character celescript's "String" token. 
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TABLE A. 5 



Metacharacter 



Meaning 



Vertical bar ( | ) 
Caret (") 



Separates alternatives . 
Either anchors to the string's 
beginning, or inverts the 
matching rules . 
Anchors to the string's end. 
Begins a nested pattern. 
Ends a nested pattern. 
Begins a character class. 
Ends a character class. 



5 



Dollar sign ($) . . 
Left parenthesis ("{ 
Right parenthesis ( " 



0 Left bracket ( D 
Right bracket (] ) 
Asterisk (*) . . 
Plus sign ( + ) . . 
Question mark (?} 



An item zero or more times. 
An item one or more times. 
An item optionally. 



5 Minus sign (-) . . . . Separates the characters defining 



Reverse slash (\) . . . Disarms the metacharacter that 
follows . 

C 3 TELESCRIPT CLASS OVERVIEWS 

Being object-oriented, the Instruction Set comprises 
certain predefined classes which are overviewed in this 
section of this appendix. These classes are divided into 
groups as discussed below. A subsection is devoted to 

5 each group. Within each subsection, a subsection is 
devoted to each class in the group. 

Being interpreted, the Instruction Set does not 
define statement forms--e.g., for control flow- -but rather 
relies upon the operations of izs classes. Thus the 

0 semantics of the Instruction Set are largely those of the 
predefined classes. 

3 . 1 Groups 

The Instruction Set's predefined classes are divided 
into groups, one of which is called the kernel. This 



Period ( . ) 



a range . 

Matches any character. 
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division serves pedagogic purposes alone, and is intended 
to suggesc neither that the classes in groups other than 
the kernel can be implemented by means of the kernel, nor 
that an Engine need implement the classes in the kernel 
5 but not necessarily these in other groups. 
The following groups are defined: 

Kernel 

This group provides basic language machinery, e.g., 
classes, objects, references, procedures, execution, and 
10 exceptions. 

Primit ives 

This group provides basic forms of indivisible 
information, e.g., booleans, octets, numbers, characters, 
and times. 

15 Collections 

This group provides basic forms of composite 
information, e.g., sets, lists, stacks, strings, and 
dictionaries . 

Class Definition 
20 This group provides the component parts of class 

definitions, e.g., interfaces, attributes, operations, 
implementations , and methods. 

Identification 

This group provides for naming and addressing, e.g., 
25 telenames and teleaddresses . 

Processes 

This group provides for multi -tasking , e.g., 
processes, permits, resources, and contacts. 

Aoents and Places 
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This group provides for process movement within a 
network, e.g., places, agents, and tickets. 

Meet inas 

This group provides for process interaction within a 
5 network node, e.g., meeting places and petitions. 

Miscellaneous 

This group provides a variety of things, e.g., a 
random number generator and a pattern matcher. 

The groups are presented below in the order in which 
0 they are listed above. The classes within each group are 
presented in alphabetical order. 



3 • 2 Kernel Group 
Qbiecr (Referenced) 

Class (Cited & Interchanged) 
Collection 

• Set (Verified) 

• • Constrained Set (Constrained) 

• • • Package (Cited & Interchanged) 
Constraint 

Exception (Unchanged) 

• Programming Exception 

• • Kernel Exception 

• • • Execution Excep t inn 

• • • • Unexpected Excep tion 
Primitive (Executed & Unchanged) 



• 


Identifier 


• 


• Cualif 


• 


Mark 


• 


Modifier 


• 


Nil 


• 


Procedure 


• 


Selector 




Constrained 



146 



EP 0 634 719 A2 



Executed 



Referenced 



Unchanged 



Verified 



5 3.2.1 



Class 



Operations 



convert 



islnstance 



isMember 



0 



isSubclass 



new 



A "class" is an immutable object that defines a set 
of objects, the class' instances. 

A class' native operations create a new instance via 
5 operation "new", convert an instance of another class to 
an instance of this one via operation "convert", indicate 
whether an object is an instance via operation 
"islnstance" or a member via operation "isMember" of the 
class, and indicate whether another class is a subclass o 
0 the present one via operation "isSubclass". 

3.2.2 Constrained 
Attributes 

constraint 

A "constrained object" enforces a constraint upon 
5 those of its properties identified by another class of 
which the object is a member. 

A constrained object's native attribute is the 
constraint (attribute "constraint") . 



Note : 



Constrained dictionaries, lists, and sets are 
constrained objects. 



0 



3.2.3 



Constraint 
Attributes 

classld 
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islnstance 
isOptional 
of Class 
passage 

5 A "constraint" is an object defining restrictions 

placed upon other objects. 

A constraint's native attributes are the identifier 
of the class of which the constraint's subjects shall be 
members (attribute "classld"), the class itself (attribut 
L0 "ofClass"), whether the subjects shall be instances of 
that class (attribute "islnstance"), whether the subjects 
may be nils (attribute "isOptional"), and the subjects' 
passage (attribute "passage"). 

3.2.4 Exception 
.5 Operations 

throw 

An "exception" is an object describing a performance 
or execution failure. 

An exception's native operation throws the exception 
0 (operation "throw"). 

3.2.5 Executed 
Operations 

catch 
do 

5 either 
if 

loop 

repeat 

while 

0 An "executed object" is permitted as an item of a 

procedure . 

An executed object's native operations perform the 
executed object (i) once via operation "do", (ii) once 
catching certain exceptions via operation "catch", (iii) 
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once iff a precondition is satisfied via operation "if", 
(iv) a certain number of times via operation "repeat", (v) 
indefinitely many times via operation "loop", cr (vi) as 
often as another executed object's performance dictates 
5 via operation "while". An additional operation decides 
which of :wo executed objects to perform {operation 
"either") . 

Note: Instances of the predefined concrete subclasses 

of class "Primitive", as well as the predefined 
10 subclasses of class "Constrained List", are 

executed objects. 



20 3.2.6 Execution Exception 

An "execution exception" is a kernel exception that 
indicates that the Engine is unable to execute an item of 
15 a procedure. 

25 

Among this class' predefined subclasses is "Internal 
Exception", a member of which indicates that the Engine 
fails to implement an aspect of the Instruction Set. The 
30 ideal Engine never throws such an exception, but an actual 

20 Engine does. The latter' s documentation says when, e.g., 
when the sum of two integers is too large for the Engine 
to conveniently represent internally. 

35 

3.2.7 Identifier 

An "identifier" is a primitive that distinguishes one 
40 25 object frcm others in a particular context. 



3.2.8 Kernel Except ion 

A "kernel exception" is a programming exception 
45 thrown by members of the classes in this section. 



3.2.9 Mark 

30 A "mark" is a primitive with one possible value, 

50 

"mark". A mark is used to demarcate a series of objects, 
usually the topmost items of a stack. 



55 
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3.2.10 Modifier 

A "modifier" is a primitive with these possible 
values : "demarcate" , "getClass" , "getProperty" , 
"get Variable" , "mention" , "set At tribute" , "set Property" , 
"setVariable" , and "useStack" . A modifier is used to 
alter the execution of the item that immediately fellows 
the modifier in a procedure. 

3.2.11 Nil 

A "nil" is a primitive with one possible value, 
"nil". A nil is used to indicate the absence, e;g., on 
the stack, of a member of another class. 

3 . 2 . 12 Obiect 
Attributes 
class 
size 

Operations 

copy 

finalize 

initialize 

isEqual 

select 
Internal Operations 

getAttribute 

getClass 

getProperty 

getvariabie 

setAttribute 

setProperty 

setVariable 

An "object" is the Instruction Set's unit of both 
information and information processing. An object is an 
instance of a class. 

An object's native attributes are its class ("class") 
and its size ("size"). 
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An object's native operations initialize (operation 
5 "initialize") and finalize (operation •'finalize") the 

object; decide whether the object equals another object 
(operation " isEqual " ) ; decide which, if any, of several 
5 objects the former object equals, and perform the executed 
10 object paired with that object (operation "select"); and 

create a separate but equal copy of itself (operation 
"copy" ) . 

An object has a number of internal features. An 
10 "internal" feature is a system feature that is sealed by 
class "Object" and, furthermore, that dees not prevent a 
feature native to a user-defined subclass of class 
20 "Object" from having the same identifier. Thus an 

internal feature is fictitious. Its only purpose is to 
15 simplify the definition of the Instruction Set, especially 
its execution model . 
25 An object's internal operations bind to objects at 

run time the identifiers used in the interface and 
implementation of the object's class. Thus an object can 
20 (i) cet via operation "qetAttribute " , or set, v^a 

30 

operation " setAt tribute " , the attribute of itself that a 
certain identifier denotes, (ii) get via operation 
"getProperty " , or set via operation "setProperty " , the 

35 property of itself that a certain identifier denotes, 

25 (iii) get, via operation "getVariable " , or set, via 
opeation " setVar iable " ( the variable that a certain 
identifier denotes, and, (iv) identify and locate the 

40 class that a certain identifier denotes via operation 

"getClass" . 

30 3.2.13 Package 

45 * . i ■ 

A package" is a constrained set of classes. A 

package, furthermore, is a cited object, a peer of each 

class the package comprises. 

50 0n « package is backward compatible with another iff 

35 the former can be created from the latter by making only 
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changes of the following kinds. First, a new class may be 
added. Second, an existing class may be replaced with one 
backward compatible with the existing class. 

3.2.14 Procedure 

A "procedure" is a primitive comprising an ordered 
set of executed objects, 

3.2.15 Programming Except ion 

A "programming exception" is an exception that 
indicates that a programming mistake was made in the 
provision or use of a feature. 

3.2.16 Qualified Identifier 

A "qualified identifier" is an identifier that 
denotes a feature and a class to which an implementation 
of the feature is either native or inherited. 

3.2.17 Referenced 
Attributes 

isProtected 

Qoerat ions 

discard 
isSame 
protect 
ref 

A "referenced" object is one to which references can 
be obtained. Its features manipulate the references used 
to request them, not the cbject itself. 

A referenced object's native attribute reveals 
whether a reference is protected (attribute 
"isProtected" J . 

A referenced object's native operations create new 
references to the object (operation "ref"), protected if 
desired {operation "protect"); discard an existing 
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reference (operation "discard"); and say whether two 
references are to the same object (operation "isSame"). 
Note : Ail objects are referenced objects. The presen 

class, then, is defined for purely pedagogic 
5 reasons . 

3.2.18 Selector 

A "selector" is a primitive with these possible 
values: "break", "client", "continue", "escalate", "here" 
"process", "self", and "succeed". A selector is used to 
0 achieve a special execution effect. 

3.2.19 Unchanged 

An "unchanged" object cannot be changed. The meanin 
of "change" depends upon the other classes of which the 
unchanged object is a member. An unchanged object often 
5 is described as "immutable". 

Note : Members of classes "Class", "Exception", 

"Package", "Primitive", and "Time" are 
immutable . 

3.2.20 Unexpected Exception 
0 Attributes 

exception 

An "unexpected exception" is an execution exception 
that indicates that a feature threw an exception whose 
class the feature does not declare. 
5 An unexpected exception's native attribute is the 

undeclared exception (attribute "exception"). 

3.2.21 Verified 
Ooerat ions 

verify 

0 A "verified object" can become internally 

inconsistent in one or more ways which depend upon the 
other classes of which the object is a member. 
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A verified object's native operation indicates 
whether the object is internally consistent (operation 
" verify" ) . 

Note: Sets are verified objects. 

5 3.3 Primit ive Group 
Obj ect ( Referenced) 

• Exception (Unchanged) 

• • Programming Exception 

• • • Primitive Exception 

10 • Primitive (Executed & Unchanged) 

• • Bit (Ordered) 

• • 3oolean (Ordered) 

• • Character (Cased & Ordered) 

• • Number (Ordered) 
15 • • • Integer 

• • • Real 

• • Octet (Ordered) 

• Telenumber 

• Time (Ordered Sc Unchanged) 
2C Cased 

Ordered 

3.3.1 Bit 

A "bi^" is a primitive with two possible values, 
"zero" and "one". 

2 Boolean 
Operations 
and 
not 
or 

A "boolean" is a primitive with two possible values, 
se" and "true" . 
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A boolean' s native operations make it capable of 
logical conjunction (operation "and"), disjunction 
(operation "or"}, and negation (operation "not"). 

3.3.3 Cased 
Attributes 

is Lower 
isUpper 

Operations 

makeLower 
makeUpper 

A "cased" object comprises character information. 
Such information, and thus the cased object itself, can be 
upper-case, lower-case, or a mix of the two. 

A cased object's native attributes indicate whether 
any character information is lower-case (attribute 
"isLower") or upper-case (attribute " isUpper" ) . 

A cased object's native operations produce an all 
lower-case (operation "makeLower") or an all upper-case 
(operation "makeUpper"} equivalent of the object. 
Note : Two cased objects can be compared without regard 

for their cases by using operation " isEqual" in 
combination with either operation "makeLower" or 
operation "makeUpper" . 
Note : Characters and strings are cased objects. 

3.3.4 Character 

A "character" is a primitive whose possible values 
are the Unicode characters [Unicode] . 

3.3.5 Integer 
Operations 

modulus 
quotient 

An "integer" is a number that is also an integer. 
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An integer's native operations perform integer 
division and produce either the quotient: (operation 
"quotient") or the remainder (operation "modulus' 1 ) that 
results . 

5 Note : Internally the Engine may represent integers 

with only finite precision. Not all integers, 
therefore, are necessarily instances of this 
class in practice. 

3.3.6 Number 
0 Operations 

abs 
add 

ceiling 
divide 
5 floor 

multiply 
negate 
round 
subtract 
0 truncate 

A "number" is a primitive that is capable of basic 
arithmetic operations. 

A number's native operations perform addition 
(operation "add' 1 ), subtraction (operation "subtract"), 
5 multiplication (operation "multiply"), and division 

(operation "divide"); negation {operation "negate") and 
absolute value (operation "abs"); rounding (operation 
"round") and truncation (operation "truncate"); and the 
floor (operation "floor") and ceiling (operation 
0 "ceiling") functions. 

3.3.7 Octet 

An "octet" is a primitive comprising eight bits. For 
reference purposes, the bits are designated Bit 7 through 
Bit 0. 
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3.3.8 Ordered 
Operations 

isAf tier 
isBef ore 
max 
min 

An "ordered" object is a member of another class 
whose members can be ordered by placing any one either 
before, after, or coincident with any other. The meanings 
of "before" and "after" depend upon that class. 

An ordered object's native operations indicate 
whether one such object is befcre (operation "isBefore" ) 
or after another {operation "isAfter") , and which of two 
is the minimum (operation "min") or the maximum (operation 
"max") . 

Note : Whether two ordered objects are coincident is 

indicated by operation "isEqual" . 
Note: Instances of many classes are ordered objects. 

3.3.9 Primitive 

A "primitive" is an cbject that is an Instruction Set 
primitive . 

Note : Net every Instruction Set primitive is a member 

of this class. 



3.3.10 Primitive Exception 

A "primitive exception" is a programming exception 
thrown by members of the classes in this section. 



3.3.11 Telenumber 
Attributes 

country 

extension 

telephone 
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A "telenumber" is an object giving the address of a 
telephone instrument in the international telephone 
network, i.e., a telephone number. 

A telenumber' s native attributes are the code for the 
5 country in which the instrument is located ("country"), 
the number the country assigns to the instrument 
("telephone"), and its telephone extension, if any 
( " extension " ) . 

3 . 3 . 12 Time 
0 Operations 

adj ust 
interval 

A "time" is an object that identifies a date and time 
of day to the precision of one second using UTC . A time 
5 also records the time zone in which it was measured and to 
what extent, if any, DST was in effect then and zhere , 
A time's native operations adjust the time by any 
number of seconds (operation "adjust") and give the 
interval between the time and another time (operation 
C " interval" ) . 

3 . 4 Collection Group 
Object (Referenced) 

• Association (Ordered) 

• Collection 
List (Ordered) 

• Constrained _ist (Constrained) 

• • Bit String (Executed) 

• • Octet String (Executed) 

• • String (Cased & Executed) 

• Stack 
Set (Verified) 

• Constrained Set (Constrained) 

• Dictionary 

• • Constra ined Dictionary (Constrained) 
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• • • • • Lexicon 

• Exception (Unchanged) 

• • Programming Exception 

• • • Collect ion Exception 
5 • Stream 

Hashed 

3.4.1 Association 
Attributes 

key 

0 value 

An "association" is one object that comprises two 
objects, which are the one object's "key" and "value". 

An association's native attributes are its key 
(attribute "key") and its value (attribute "value"). 
5 Note : Associations are used tc create dictionaries. 

3.4.2 Bit String 

A "bit string" is a constrained list whose items are 
instances of class "Bit 11 . 

3.4.3 Collection 
0 Attributes 

length 

Operations 

clear 
examine 
5 exclude 
include 
stream 

A "collection" is an object that comprises an 
unordered set of zero cr more ether objects, its "items", 
0 which are among its properties. A collection's "length" 
is the number of the collection's items. The collection 
is "cleared" if its length is zero. A subclass of class 
"Collection" can restrict ics members' items. 
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A collection's native attribute is the collection's 
length (attribute "length"). 

A collection's native operations include an object as 
a new item (operation "include"), exclude an existing item 
5 (operation "exclude"), exclude all existing items 
(opeation "clear"), arrange for an item's inspection 
{operation "examine"), and produce a stream whose items 
are those of the collection (operation "stream"). 
Note: A collection's length is unbounded. 

10 3.4.4 Collection Exception 

A "collection exception" is a programming exception 
thrown by members of the classes in this section. 

3.4.5 Constrained Dictionary 

A "constrained dictionary" is a dictionary whose keys 
L5 are restricted by means of a constraint, a single 
constraint governing the entire dictionary. 

3.4.6 Constrained Lisr 

A "constrained list" is a list whose items are 
restricted by means of a constraint, a single constraint 
10 governing the entire list. 

3.4.7 Constrained Set 

A constrained set is a set whose items are restricted 
by means of a constraint, a single constraint governing 
the entire set . 

5 3.4.8 Dictionary 
Operations 

add 
drop 
find 
0 get 

rekey 
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sec 

transpose 

A "dictionary" is a sec whose items are associations. 
A subclass of class "Dictionary" can restrict its members' 
keys, values, or both. 

A dictionary's native operations include an 
association between a certain key and a certain value as a 
new item (operation "add"), exclude the association with a 
certain key {operation "drop")/ determine a key's 
associated value {operation "get"), replace a key's 
associated value {operation "set"), determine a value's 
associated key (operation "find"), replace one key with 
another {operation "rekey"), and transpose two keys 
{operation "transpose"). 

3.4.9 Hashed 
Attributes 

hash 

A "hashed" object is a member of another class for 
which a hash function is defined. Each member of that 
class computes its own hash, an integer, ensuring chat if 
two members are equal, their hashes are equal. 

A hashed object's native attribute is the hash 
function for that object (attribute "hash"). 
Note: If a dictionary's keys are hashed objects, the 

dictionary can, but need not, use attribute 
"hash" in the performance of some of the 
dictionary's operations. 
Note: No instances of predefined classes are hashed 

ob j ects . 

3.4.10 Lexicon 

A "lexicon" is a constrained dictionary whose keys 
are identifiers. 

3.4.11 List 
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Operations 

add 
drop 
find 
5 get 

reposit ion 
set 

transpose 

A "list" is a collection whose items are numbered in 
10 [1 ( n] , "n" being the collection's length. An item's 
number is the item's "position" in the list. 

A list's native operations include an object as a new 
item (operation "add") ( exclude an existing item 
(operation "drop"), arrange for an item's inspection 
15 (operation "get"), replace an existing item (operation 
"set"), determine an existing item's position (operation 
"find"), reposition an existing item (operation 
"reposition"), and transpose two existing items (operation 
"transpose" ) . 



is a constrained list whose items 
"Octet " . 



0 3.4.12 Octet String 
An "octet string" 
are instances of class 



3.4.13 Set 

Operations 

difference 

intersection 

union 

A "set" is a collection no two of whose items are 
equal when included. 

A set's native operations compute the union 
(operation "union") or intersection (operation 
"intersection") of two sets and exclude those items in one 
that equal items in the other (operation "difference"). 
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Note : An item's modification in situ, may leave two 

items equal. 

3 . 4 . 14 Stack 
Cperat ions 
5 pop 
push 

pushl terns 

roll 

swap 

0 A "stack" is a list whose items are usually dropped 

in the order that is the opposite of that in which they 
were added. The stack's "top" is position one, the 
stack's "bottom" the position that is the stack's length. 
A stack's native operations add an object at the top 

5 (operation "push"), add the items of a list at the top 
(operation "pushltems"! , drop the item at the top 
(operation "pop"), transpose the two items at the top 
(operation "swap"), and roll a certain number of the 
topmost items a certain number of positions (operation 

0 "roll") . 

3.4.15 Stream 
At t r ibutes 

current 
isDone 
5 next 

A "stream" is an object that provides sequential 
access to the objects in an associated series of objects, 
the stream's "items". A stream never "produces" the same 
item twice, and produces a nil after producing the last 
0 item. 

A stream's native attributes enable it to produce its 
next item upon request (attribute "next"), reproduce the 
item it produced most recently (attribute "current"), and 
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indicate whether or not it has yet produced its last item 
(attribute "isDone") . 

Note : If an item of the stream is itself a nil, this 

fact must be taken into account when 
interpreting the "next" or "current" attribute. 

3.4.16 String 
Operations 

substring 

A "string" is a constrained list whose items are 
instances of class "Character" . 

A string's native operation produces a copy of a 
substring (operation "substring"). A substring is a 
series of zero or more characters occupying successive 
positions in a string. A substring is defined by two 
positions, P x and P 2 , the substring's items being those at 
positions [P,, P : ) of the string. 

3 . 5 Class Definition Group 
Object (Referenced) 

• Class Definition 

• Exception (Unchanged) 

• • Programming Exception 

• • • Class Exception 

• Feature 

• • Attribute 

• • Ope rat ion 

• Implementation 

• Interface 

• Method 

3 ■ 5 * 1 Attribute 
Attributes 

constraint 
isSet 
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An "attribute definition", i.e, a member of class 
"Attribute" , is a feature definition for an attribute. 

An attribute definition's native attributes define 
how the attribute is constrained (attribute "constraint") 
5 and whether it can be set (attribute "isSet"). The former 
affects both the result of operation "aGet" and, if the 
attribute can be set, the argument of operation "aSet". 

3.5.2 Class Definition 

Attributes 
10 implementation 

interface 

ma jorEdit ion 

minorEdition 

title 

15 Operations 

makeClasses 

A "class definition" is an object that defines a 
class . 

A class definition's native attributes define the 
20 class' interface (attribute "interface";, implementation 
(attribute "implementation"), title (attribute "title"), 
major edition (attribute "ma jorEdition" ) , and minor 
edition (attribute "minor^dit ion" ) . 

A class definition's native operation creates the set 
25 of one or more classes that a set of as many class 
definitions define (operation "makeClasses"). Any- 
required references among the classes are established as 
the classes are created. The process requesting the 
operation is the classes' author. 

30 3.5.3 Class Exception 

A "class exception" is a programming, exception thrown 
by members of the classes in this section. 

3.5.4 Feature 
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Attributes 

except ions 
isPublic 

A "feature definition", i.e, a merrier of class 
"Feature", is an object that defines a particular feature 
of every member of the class of whose interface the 
feature definition is a part. 

A feature definition's native attributes define 
whether the feature is public, not private (attribute 
"isPublic"), and the classes of which the feature's 
exceptions are members (attribute "exceptions"). A system 
feature is not subject to a feature definition. 

3.5.5 Implementation 
Attributes 

classMethods 

f rorruMethods 

instanceMethods 

properties 

setMethods 

superclasses 

tcMethods 

vocabulary 

An "implementation" is an object that implements 
selected features and conversions native to or inherited 
by the class of which the implementation is a part. 

An implementation's native attributes identify the 
implementation's immediate implementation superclasses 
(attribute "superclasses"); provide methods for selected 
class features (attribute "classMethods"), instance 
features (attribute "instanceMethods" and attribute 
"setMethods"), and conversions from (attribute 
"f romMethods") and to (attribute " toMet hods " ) ether 
classes; define properties native to the class (attribute 
"properties"); and define the identifiers the 
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implementation uses to denote user-defined classes 
(attribute "vocabulary") . 

3.5.6 Incerface 
Attributes 
5 classFeatures 

instance Features 
isAbstract 
seaLedClassFeatures 
se a ledlnstance Features 
10 superclasses 
vocabulary 

An "interface" is an object that defines the features 
native to the class of which the interface is a part. 

An interface's native attributes define whether the 
15 class is abstract (attribute " isAbstract " ) , identify the 
class' immediate interface superclasses (attribute 
"superclasses"), define the class' native class features 
(attribute "classFeatures") and instance features 
(attribute " instanceFeatures " ) , identify che class 
20 features (attribute " sealedClassFeatures " ) and instance 
features (attribute n sealedlnstanceFeatures " ) that the 
class seals, and define the identifiers the interface uses 
to denote user-defined classes (attribute "vocabulary"). 

3.5.7 Method 
25 Attributes 

procedure 
variables 

A "method" is an object that is used to implement a 
feature . 

30 A method's native attributes are the method's 

procedure (attribute "procedure") and the identifiers of 
the method's variables (attribute "variables"). 
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3.5.8 Operation 
Attributes 

arguments 
result 

5 An "operation definition", i.e., a member of class 

"Operation", is a feature definition for an operation. 

An operation definition's native attributes define 
whether the operation's arguments are variable or fixed in 
number and, in the latter case, how each argument is 
10 cons-rained (attribute "arguments"}. The attributes also 
define whether the operation has a result and, if so, hew 
the result is constrained (attribute "result") . 

3 ■ 6 Identification Group 
Obj ect (Referenced) 
15 • Citation (Ordered) 

• Teleaddress 

• Te lename 
Cited 

Named 

V 

20 3.6.1 Citation 
Attributes 

author 

majorEdition 
minorEdition 
25 title 

A "citation" is an object that identifies zero or 
more editions, e.g., classes, in the Telescript Network. 

A citation's native attributes define the title in 
which the editions appear (attribute "title"); optionally, 
0 the title's author (attribute "author"); and, optionally, 
the editions' major edition (attribute "majorEdition"}, 
miner edition (attribute "minorEdition"), crboth. 

3.6.2 Cited 
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Attributes 

citation 

A "cited" object is one having an assigned citation. 
Two cited objects are peers iff the assigned telenames in 
5 their assigned citations are peers. 

A cited object's native attribute is the object's 
assigned citation (attribute "citation"). 
Note: Classes and packages are cited objects. 

3.6.3 Named 
0 Attributes 

name 

A "named" object is one having an assigned telename. 
Two named objects are peers iff their assigned telenames 
are peers . 

5 A named object's native attribute is the object's 

assigned telename (attribute "name"). 
Note : Processes are named objects. 

3.6.4 Teleaddress 
Attributes 

0 location 
provider 
routingAdvice 
A " teleaddress" is an object that locates zero or 
more places in the Telescript Network. 
5 A teleaddress' native attributes give the places' 

region (attribute "provider"); optionally, the places' 
location (attribute "location"}; and any routing advice 
(attribute " rout ingAdvice " ) . 

3.6.5 Telename 
0 Attributes 

authority 
identity 
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A "telename " is an object that identifies zero or 
more named objects in the Network. 

A telename 's native attributes define the named 
objects' authority (attribute "authority") and, 
5 optionally, the single named object's identity (attribut 
" ident i ty " ) . 



3 . 7 Process Group 
Object (Referenced) 

• Contact 

0 • Exception (Unchanged) 

• • Programming Exception 

• • • Process Exception 

• Permit (Ordered) 

• Process (Named) 
5 • Resource 

Contacted 



3.7.1 Contact 
Attributes 

subject 
0 subjectClass 
subjectName 
subj ectNotes 
A "contact" is an object that represents and 
documents for one process its interaction with another. 
5 A contact's native attributes are the subject 

(attribute "subject"), the subject's assigned telename 
(attribute "subjectName"), the subject's class' assigned 
citation (attribute "subjectClass"), and an object the 
observer maintains (attribute " sub j ectNotes " ) . Even if 
C the subject attribute is a nil, as it may be, the Engine 
guarantees the authenticity of the other attributes. 
Note: Typically the "subj ectNotes " attribute is the 

state of the interaction between the two 
processes from the observer's viewpoint. 
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3.7.2 Contacted 
Attributes 

contacts 

A "contacted" object, necessarily a process, receives 
5 help from the Engine in maintaining the object's set of 



10 contacts . 



A contacted object's native attribute is the object's 
contacts (attribute "contacts") . 

Note: Instances of no predefined classes are contacted 

- c objects. 



3.7.3 Permit 
A 

prccess 



A "permit" is an object that grants capabilities to a 



Attributes 
25 is age 

authenticity 
canCharge 
canCreate 
canDeny 
2C canGo 

canGrant 
canRestart 
canSend 
charges 
25 extent 

priority 

A permit's native attributes include integers that 
define the maximum age (attribute "age"), size {attribute 
"extent") , charges (attribute "charges"), priority 
30 (attribute "priority"), and authenticity (attribute 
"authenticity") of the permit's subject. 

A permit's native attributes include booleans that 
can permit the subject to request operation "charge" 
(attribute "canCharge"), operation "go" (attribute 
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"canGo") , operation "send" (attribute "canSend"), or 
operation "new" of a subclass of class "Process" 
(attribute " canCreate " ) ; deny (attribute "canDeny") or 
grant (attribute "canGranc") capabilities via certain 
5 permits of certain processes; and be restarted (attribut 
"canRestart" ) . 



Operations 

intersection 

A permit's native operation return the intersection 
0 of two permits (operation "intersection") , 



3.7.4 Process Exception 

A "process exception" is a programming exception 
thrown by members of the classes in this section. 



3.7.5 Process 
5 Attributes 

age 
brand 
charges 
localPermit 
0 permit 

priority 
privateClasse - 
regionalPermit 

Operations 
5 charge 
live 

restrict 
restricted 
sponsor 
0 wait 

A "process" is a named object that constitutes an 
autonomous computat ion . 



172 



EP0 634 719 A2 



A process' native attributes are the process' age 
(attribute "age"), brand (attribute "brand"), charges 
(attribute "charges"), local permit (attibute 
"localPermit " ) , permit (attribute "permit"), priority 
5 (attribute "priority"), privately held and used classes 
(attribute "privateClasses" ) , and regional permit 
(attribute " regionalPermit " ) . 

A process' native operations carry out the process' 
autonomous computation (operation "live"), delay the 
LO computation for a period of time (operation "wait"), 

impose a temporary permit cn the process itself (operatio 
"restrict"), perform a procedure under a temporary permit 
and the resulting effective permit of the respcnder's 
owner {operation "sponsor") , and charge another process 
.5 for services chat the present process provides to the 
other process (operation "charge"). 

3.7.6 Resource 
Attributes 

condit ion 
0 conditions 
Operations 

use 

A "resource" is an object about which certain 
guarantees can be made to a process throughout the 

5 process' performance of a particular procedure. 

A resource's native attributes are the resource's 
current condition (attribute "condition") and the 
identifiers of the resource's possible conditions 
(attribute "conditions") 

0 A resource's native operation performs a certain 

procedure once the resource has made the guarantees 
requested of the resource (operation "use"). 

3 . 3 Agent and Place Group 
Object (Referenced) 
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• Authenticator 

• Exception (Unchanged) 

• • Trip Exception 

• Means 

5 • Process (Named) 

• • Aaent 

• • Place ( Unmoved ) 

• Ticket Stub 

• • Ticket 
0 • Way 

Unchanged 

• Interchanged 
Unmoved 



3.3.1 Agent 
5 Operations 

go 

send 

An "agent" is a process that can move from place to 
place . 

0 An agent's native operations transport the agent to 

one destination (operation "go") or one or more clones to 
as many destinations concurrently (operation "send"). 

3.8.2 Authenticator 

An "authenticator" is an object with which the 
5 Network can authenticate an agent that initiated a trip, 
e.g., as the agent passes between regions. 

Note: Concrete subclasses of class "Authenticator" are 

region-specific and thus user-defined. 

3.3.3 Interchanged 
Attributes 

digest 
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An "interchanged" object is an unchanged object for 
which the Network may substitute an equivalent object 
whenever the object's owner takes a trip. 

An interchanged object's native attribute is the 
5 object's digest (attribute "digest"). 

3.3.4 Means 

A "means" is an object that identifies a means, e.g., 
a particular wireless communication medium, by which the 
Network can transport an agent that initiated a trip from 
0 the trip's source, to the trip's destination, cr both. 
Note: Concrete subclasses of class "Means" are 

region-specific and thus user-defined. 

3.5.5 Place 
Attributes 

5 address 

publicClasses 

Operations 

entering 
exiting 
C terminate 

A "place" is a process that is the locale for zero or 
more other processes. 

A place's native attributes are the place's address 
(attribute "address") and the place's publicly held and 
5 used classes (attribute publicClasses"). 

A place's native operations pass judgment upon a 
process' proposed entry of the place (operation 
"entering"), take note of the process' exit from the place 
(operation "exiting"), and forcibly terminate an occupant 
0 (operation "terminate"), provided the requester is 
sufficiently capable (attribute "canTerminate " of the 
requester's permit) and the occupant's peer. 

3.3.6 Ticket 
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Attributes 

desiredWait 
destinationAddress 
dest inat ionClass 
5 destinationNarne 

dest inat ionPermi t 
maximumWait 

A "ticket" is a ticket stub that describes an 
intended trip from the viewpoint of the agent taking the 
10 trip. The ticket's main purpose is to identify the trip's 
destination. 

A ticket's native attributes are a telename 
(attribute "destinationNarne"} and a teleaddress (attribute 
"destinaticnAddressa") of the destination, a citation to a 
15 class of which the destination is a member (attribute 
"destinationClass") , the local permit the agent needs at 
25 the destination (attribute "dest inat lonPermit " } , the time 

interval within which, ideally, the trip should be made 
(attribute "desiredWait"), and the time interval within 
20 which, under any circumstances, the trip shall succeed or 
fail (attribute "maximumWait"). 

3.8.7 Ticket Stub 

Attributes 

travelNotes 
2 5 way 

A "ticket stub" is an object that describes the 
results of a trip. 

A ticket stub's native attributes are the way back to 
the trip's origin (attribute "way") and information, 
30 present originally on the ticket, for the exclusive use of 
45 the agent that initiated the trip (attribute 

" travelNotes" ) . 

3.8.8 Trip Exception 

50 Attributes 
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ticketStub 

A "crip exception" is an exception that signifies the 
Network's failure to provide the trip that a ticket 
describes . 

5 A trip exception's native attribute is the ticket 

stub {attribute " t icketStub" ) . 

3.8.9 Unmoved 

An "unmoved" object cannot be moved from one place to 
another. An unmoved object often is described as 
G immovable. 

A reference to an unmoved object is voided if 
movement of the object is attempted. 
Note : Places are immovable. 

3 . 8 . 10 Way 
5 Attributes 

authenticates 

means 

name 

A "way" is an object that identifies a route along 
0 which the Network can transport an agent that initiated a 
trip . 

A way's native attributes are the name of the region 
through which the trip is to proceed (attribute "name") 
and the means (attribute "means") and the authenticates 
5 {attribute " authenticates " ) to be used to enter that 
region. 



3 . 9 Meeting Group 
Object (Referenced) 

• Exception (Unchanged) 

• • Meeting Exception 

• Petition 

• Process (Named) 

• • Place (Unmoved) 
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• • • Meeting Place 
Pet it ioned 

3.9.1 Meeting Exception 

A "meeting exception" is an exception that signifies 
5 a meeting place's failure to arrange the meeting that a 
petition describes. 

3.9.2 Meeting Place 
Opera: ions 

meet 

0 part 

partAll 

A "meeting place" is a place that will arrange 
meetings between any two petitioned objects that are among 
its occupants. 

5 A meeting place's native operations begin a meeting 

(operation "meet";, end one (operation "part"), and end 
all meetings involving the requester (operaticn 
"partAll" ) . 

3.9.3 Petition 
0 Attributes 

agentClass 

agentName 

maximumWait 

A "petition" is an object that describes an intended 
5 meeting from the viewpoint of the petitioner. The 
petition's main purpose is to identify the petitionee. 

A petition's native attributes are a telename of the 
petitionee (attribute "agentName ") , a citation to a class 
of which the petitionee is a member (attribute 
0 "agentClass"), and the time interval within which the 
meeting attempt shall succeed or fail under any 
circumstances (attribute "maximumWait") . 
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3.9.4 Petitioned 
Qperat ions 

meeting 
part ing 

5 A "petitioned" object, necessarily an agent, can play 

the role of either petitioner or petitionee in the 
establishment of a meeting. 

A petitioned object's native operations pass judgment 
upon a request for a meeting (operation "meeting") and 
10 take note of a parting (operation "parting"). 
Note : Instances cf no predefined classes are 

petitioned objects. 

3.1C Miscellaneous Group 
Object (Referenced) 



15 



20 



Calendar Time 
Exception (Unchanged) 

• Programming Exception 

• • Miscellaneous Exception 
Pattern (Ordered) 

Primitive (Executed £ Unchanged) 

• Number (Ordered) 

• • Real 
Stream 

• Random Stream 
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25 3.10.1 Calendar Time 
Attributes 

day 

dayOfWeek 
dayOfYear 
30 dst 
hour 
minute 
month 
second 
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year 
zone 

Operations 

globalize 
5 localize 
normalize 

A "calendar time" is an object that identifies a 
local date and tixe of day to the precision of one second 
using UTC. A calendar time also records the local time 
0 zone and to what extent, if any, DST was in effect: then 
and there. 

A calendar time's native attributes give the time's 
hour (attribute "hour")., minute (attribute "minute"), and 
second (attribute "second"); the date's year (attribute 

5 "year"), month (attribute "month"), and day (attribute 
"day"); the cays of the week (attribute "dayCf Week" ) and 
year (attribute "dayOf Year " ) ; and, finally, the time zone 
(attribute "zone") and to what extent DST is in effect 
there (attribute "dst" ) . 

C A calendar time's native operations localize 

(operation " localize ") , globalize (operation "globalize"), 
or normalize (operation " normalize M ) the calendar time. 

3.10.2 Miscellaneous Exception 

A "miscellaneous exception" is a programming 
5 exception thrown by members of the classes in this 
section. 

3 . 10 . 3 Pattern 
Operations 

find 

C substitute 

A "pattern" is an object for lexically analyzing 
strings. The pattern's text, itself a string, dictates 
the exact nature of the analysis. 
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A pattern's native operations search a string for the 
first: matching substring (operation "find") or modify all 
matching substrings (operation "substitute"). 

3.10.4 Random Stream 
5 A "random stream" is a stream whose items are 

pseudc- randomly chosen integers in [0, M] . The icems are 
determined by an integer- -the seed- -in the same interval. 
A random stream never produces its last item. In one 
embodiment of che present invention, "M" is chosen by the 
10 creator of the random stream and is specified as an 
init ializacion oaramecer. 



3.10.5 Real 

A real is a number chat constitutes a real number in 
mathematics . 

25 15 Note : Internally the Engine may represent reals--and 

perform arithmetic operations involving 
them--with only finite precision. Not all real 
numbers, therefore, are necessarily instances of 
this class in practice, and the results of the 
23 arithmetic operations, when performed by reals, 

may be only approximate. 



4 TELESCRIFT CLASS DETAILS 

Telescript's predefined classes are defined, in 
alphabetical order, in this section of this appendix. A 
25 subsection is devoted to each class. 

4 . 1 Conventions 

A class' definition begins with a diagram of the 
portion of the class graph that encompasses that class. 
The class itself is underlined. 
30 The following sections follow as necessary in the 

discussion of each predefined class. 
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Class 

5 This section describes the class apart from the 

class' features. The class is formally defined following 
the conventions of Section 6, but an ellipsis (...) 
5 appears in place of the formal definitions of the class' 

10 

features. Described in prose is now, if at all, the 
class' interface's encoding is parameterized (see Section 
6 below) , 

15 

Construction 

10 This section describes operation "initialize" as it 

pertains to members of the class. If this section is 
20 omitted, a particular description is implied as described 

below in Section 6. 



Subclasses 
25 

15 This section comprises the definitions of the class' 

predefined immediate subclasses. This section is omitted 
iff the class is not a subclass of class "Exception" or is 
30 a subclass of class "Exception" but has no predefined 

subclasses . 

20 Attributes 

35 

These sections define the attributes native to the 
class. Separate sections are devoted to public, private, 
internal, and other system attributes of the class itself 
40 and instances of the class. A section is omitted iff it 

2 5 would be empty. 

An attribute is formally defined following the 
conventions of Section 6. The attribute's semantics and 
45 exceptions are informally defined in prose. 



Operations 

30 These sections define the operations native to the 

class in the same way that other sections, described, 
define the attributes native to the class. 
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If an operation modifies the stack that holds its 
arguments and result, the operation's effect upon the 
stack is described assuming the arguments have been popped 
from the stack and any result has yet to be pushed onto 
5 the stack. 

Adaptations 

This section describes how the class implements 
features that the class inherits. This section is omitted 
iff the class implements no such features. 

0 Conversions 

This section describes the conversions that produce 
instances of the class. This section is omitted iff there 
are no such conversions. 

The definition of an individual conversion identifies 
5 a source class and states how the source class' members 
are converted to the subject class. If not all members 
can be so converted, which can be converted are indicated. 
If the source class of one conversion is a subclass of the 
source class of another, the former conversion takes 
precedence over the latter. Conversions are not chained. 
Note: Conversion is done, i.e., in a single step. 

Thus the conversion of a telenumber to an octet 
string, e.g., is undefined, even though the 
conversion of a telenumber to a string and the 
conversion of a string to an octet string are 
defined . 

4 . 2 Agent 

Object (Referenced) 

• Process (Named) 

• • Agent 

Class 

Agent : 
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abstract interface (Process) = (...); 
Private Instanc e Ope ran' ohq 

unprotected op (ticket: copied Ticket) TicketStub 
throws PermitViolated, State Improper , TripException; 



Transports the responder to the destination 
identified by the ticket (argument "ticket"') subject to 
the ticket's other terns. The operation returns the 
ticket stub. 

10 An exception is thrown if che responder holds a 

permit that forbids operation "go" ( » PermitViolated" ) , the 
responder 's state precludes operation "go" 
("Statelmproper") , cr the trip failed ("TripException"). 



send : 



15 



unprotected op (tickets: copied List [Ticket]) 
TicketStub | Nil 

throws PermitViolated, Statelmproper, 
TripException; 

Transports a clone of che responder to the 
20 destination identified by each and every listed ticket 
(argument "tickets") subject to the ticket's other terms. 
The responder' s allowance is reduced by the amounts the 
tickets assign to the clones. The operation returns a nil 
for the responder, a ticket stub for each clone. 
25 if a member of either class "Permit Violated" or 

class "State Improper" causes the operation to fail, the 
responder experiences the failure, no clones having been 
created. Otherwise, the responder experiences the 
operation's success, and each clone, separately and 
30 independently, experiences either the operation's success 
or its failure because of a member of class "Trip 
Exception" . 
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An exception is thrown if the respcnder holds a 
permit that forbids operation "send" or whose allowance is 
less than the sum of those of the permits on the listed 
tickets { " PermitViolated" } , the responder's state 
5 precludes operation "send" ( " Statelmproper " ) , or the trip 
failed' ( "TripExcept ion" ) . 



4 . 3 Assoc iat ion 

Object (Referenced) 
• Associat ion (Ordered) 

10 Class 

Association : 

sealed interface [keyClass, valueClass: Class] 
(Object, Ordered) = (...); 

25 Parameterized by the classes of which the key 

15 (argument "keyClass") and the value (argument 

" valueClass " ) of each member of the subject class are 
themselves members. 



Construe" ion 

initialize : 

iO unprotected op (key: keyClass; value: valueClass) 

Makes the responder's native attributes the 
like-named arguments (argument "key" and argument 
"value") . 

Public Instance Attributes 
:5 kev: 

keyClass ; 



The responder's key. 
50 value : 
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valueClass ; 

The responder's value. 

Adaptations 
isAf ter 

5 One association is after another according to their 

keys . 

isBef ore 

One association is before another according to their 



keys 



10 isBcual 

Two associations are equal according to their keys. 

25 4.4 Attribute 

Object (Referenced) 
• Feature 
15 • • Attribute 



Class 

Attribute : 

sealed interface (Feature) = (...); 

Construction 
2 0 initialize : 

unprotected op ( 

constraint : Constraint j Nil ; 
isSet, isPublic: Boolean j Nil; 
exceptions: Set [ Identifier !] | Nil ) ; 

25 Makes the responder's attributes the like-named 

arguments (arguments "constraint", "exceptions", 
"isPublic", and "isSet-'). If an argument is a nil, 
however, the corresponding attribute is made a constraint 
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with nils as initialization parameters, a cleared set, 
"false" or "false", respectively. 

Public Instance Attributes 
constraint : 
5 Constraint ; 

The constraint upon the attribute that the responder 
defines . 

isSet : 
Boolean; 

0 Whether the attribute that the responder defines is 

not read-only. 

Adactat ions 
isSqual 

Two attribute definitions are equal according to 
5 their attributes native to feature definitions and 
attribute definitions . 

4 . 5 Authent icator 
Object (Referenced) 

• Authent icator 

0 Class 

Authenticator : 

abstract interface = <); 

4 .6 Bit 

Object (Referenced) 
5 • Primitive (Executed & Unchanged) 

• • Bit (Ordered) 

Class 
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Bit : 

sealed interface (Primitive, Ordered) = (); 

Adaptations 
isAf ter 

5 One bit is after another iff the first is one, the 

second zero. 

isBef ere 

One bit is before another iff the first is zero, the 
second one. 

LO isEqual 

Two bits are equal iff both are zero or one. 

Conversions 

BitStrinq 

A bit string having one item produces a bit that 
.5 equals that item. 

Boolean 

The bcoleans false and true produce zero and one, 
respectively. 

Character 

0 The numerals zero (0) and one (1) produce zero and 

one , respectively. 

Integer 

The integers zero and one produce zero and one, 
respectively . 

5 Octet 

An octet all of whose bits except Bit 0 are zero 
produces that bit. 
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OctetStrina 
5 ~ 

An occer string that can be converted to an octet 
that can be converted to a bit produces that bit. 

10 Spring 

5 A string that can be converted to a character that 

can be converted to a bit produces that bit. 

15 4 • 7 Bit String 

Object (Referenced) 

• Collection 
1C • • List (Ordered) 

• • • Constrained List (Constrained) 

• # # # Bit String (Executed) 
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Class 
BitStrinq : 

15 sealed interface (Const rainedList [Bit], Executed* 

{...}; 



Construct ion 

initialize - 

unprotected op (segments: Object 
35 20 /* Bit jprocected BitStringi */) ; 

Makes the responder a concatenation of the segments 
(argument -segments") whose positions in the responder 
increase from left to right. 

Adaptations 
2 5 constraint 



50 



The attribute is sealed. its "ofClass", "classld" 
"islnstance", -isOpcional- . and "passage" attributes ar^ 
class "Bit", the identifier of class "Bit", "true", 
"false", and "byCopy", respectively. 
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isAf ter 

One bit string is after another as if enough "zero" 
bits were first prepended tc the shorter bit string to 
make the shorter bit string equal in length to the longer 
5 bit string. 

isBef ore 

One bit string is before another as if enough "zero" 
bits were first prepended to the shorter bit string to 
make the shorter bit string equal in length to the longer 
10 bit string. 

Conversions 
Bit 

A bit produces a bit string whose only item equals 
that bit. 

15 Boolean 

A boolean produces the result of first converting the 
boolean to a bit, and then converting the bit to a bit 
string. 

Character 

0 A character produces the result of first converting 

the character to an octet string, and then converting the 
octet string to a bit string. 

Integer 

An integer in the range of [-2\ 2"), for some integer 
5 "n" and none smaller, produces a bit string of length "n" . 
A twos' complement representation is used. The bit at 
position one represents -2". The bit in each position "i" 
in the range of (l, n] represents 2"''. 

Octet 
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An octet produces the result of first converting the 
octet to an octet string, and then converting the octet 
string to a bit string. 

OctetStrina 

5 An octet string whose length is "n H produces a bit 

string whose length is »3n". The bit whose position in 
the bit string is (8i+j) is Bit (8-j) of the octet whose 
position in the octet string is "i». in the above, " i " 
and "j» are integers, "i" is in the range [0, n) , and »j« 
10 is in the range [1, 3] . 

String 

A string produces the result of first converting the 
string to an octet string, and then converting the octet 
string to a bit string. 

15 4 . S Boolean 

Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • 3oolean (Ordered) 

Class 
20 Boolean : 

sealed interface (Primitive, Ordered) = (...); 

Public Insta nce Operations 
and : 

op (boolean: Boolean) Boolean; 

25 Returns the logical conjunction of the boolean 

(argument "boolean") and the responder. 

not : 

op () Boolean; 
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Returns "he logical negation of the responder. 

or : 

op (boolean: Boolean) Boolean; 

Returns the logical disjunction of the boolean 
(argument "boolean") and the responder. 

Adaptations 
isAf ter 

One boolean is after another iff the first is "true" 
and the second is "false". 

isBef ore 

One boolean is before another iff the first is 
"false", and the second is "true". 

isEgual 

Two booleans are equal iff both are "false" or both 
are "true " . 

Conversions 
Bit 

A bit produces an indication of whether the bit is 

one . 

Character 

A character produces an indication of whether the 
character's Unicode code is non-zero. 

Collect ion 

A collection produces an indication of whether the 
collection's length is non-zero. 

Except ion 

An exception produces "true". 
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Nil 

A nil produces "false". 
Number 

A number produces an indication of whether the number 
5 is non-zero. 

Octet 

An octet produces an indication of whether any of the 
octet's bics is one. 

4 . 9 Calendar Time 
0 Object (Referenced) 
• Calendar Time 

Class 

CalendarTime : 
interface = (...); 

5 Construction 

initialize 

Makes the responder' s native attributes nils. 

Public Instance Attributes 
day : 

Integer ] Nil ; 

Either the day of the month the responder identifies 
or a nil . 

davOfWeek : 

readonly Integer j Nil ; 

Either the day of the week the responder identifies 
or a nil. 
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davOf Year : 

readonly Integer j Nil ; 

Either the day of the year the responder identif 
or a nil . 

dst : 

Integer ! Nil ; 

Either the seasonal offset in minutes, from the 
permanent offset, of the z ime zone the responder 
identifies or a nil . 

hour : 

Integer j Nil ; 

Either the hour cf the day the responder identifj 
or a nil. 

minute : 
Integer ] Nil ; 

Either the minute of the hour the responder 
identifies or a nil. 

month : 

Integer \ Nil ; 

Either the month of the year the responder identi 
or a nil . 
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second : 
Integer j Nil ; 

Either the second of the minute the responder 
identifies or a nil. 

5 year : 

Integer j Nil ; 

Either the year in the Gregorian calendar the 
responder identifies or a nil. 

zone : 

.3 Integer J Nil; 

Either the permanent offset in minutes, from UTC, of 
the time zone the responder identifies or a nil. 

Public Instance Operations 
global ize : 
5 unprotected op (); 

Sets the responder' s permanent and seasonal offsets 
to those of UTC so that the absolute point in time 
identified is unchanged. 

local ize : 
0 unprotected op (); 

Sets the responder' s permanent and seasonal offsets 
to those of the current place so that the absolute point 
in cime identified is unchanged. 

normalize : 
5 unprotected op () Boolean; 
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Normalizes the responder and returns an indication 
whether any cf the responder' s attributes were altered i 
the process. 

Adaptations 
5 isEqual 

Two calendar times are equal according to their 
native attributes. 

Conversions 
Time 

.0 A time produces a normalized calendar time that 

identifies the same absolute point in time and the same 
permanent and seasonal offsets. 

4 . 10 Cased 
Cased 

5 Class 

Cased : 

abstract interface ( ; = (,..),* 

Public Insta nce Attributes 
isLower : 

abstract readonly Boolean; 



0 



ase . 



Whether any item of the responder is lower-c 
isUocer : 

abstract readonly Boolean; 

Whether any item of the responder is upper-case. 

5 Public Instance Operat-i nrg 
makeLcwer : 

abstract op () copied Cased; 
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Returns a copy of the responder in which every 
upper-case item has been replaced with the item's 
lower-case equivalent . 

makeUpper : 
5 abstract op () copied Cased; 

Returns a copy of the responder in which every 
lower-case item has been replaced with the item's 
upper-case equivalent . 

4.11 Character 
0 Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Character {Cased & Ordered) 

Class 

Character : 

5 sealed interface (Primitive, Cased, Ordered) = () 

Adaptations 
isAf ter 

One character is after another according to their 
Unicode codes. 

0 isBef ore 

One character is before another according to thei 
Unicode codes. 

isEaual 

Two characters are equal according to their Unicoi 
5 codes. 

Conversions 
Bit 
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The bit "zero" produces the numeral zero (0) , and th 
bit one produces the numeral one (1) . 

Integer 

An integer in the range of [0, 65535] produces the 
5 character with that Unicode code. 

Octet 

An octet produces the result of first converting the 
octet to an integer, and then converting the integer to a 
character . 

0 OctetString 

An octet string produces the result of first 
converting the octet string to an integer, and then 
converting the integer to a character. 

String 

5 A string having one item produces a character that 

equals that item. 

4 . 12 Citation 

Obj ect (Referenced) 

• Citation (Ordered) 

0 Class 

Citat ion : 

interface (Object, Ordered) = (...); 

Construction 

initialize : 
5 unprotected op ( 

title: Identifier!; author: Telename j Nil ; 
majorEdition, minorEdi t ion : IntegerjNil) 
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Makes the responder's native attributes the 
like-named arguments (arguments "author", "majorSdition" , 
"minorEdition" , and "title"). 

Public Instance Attributes 
5 author : 

Telename j Nil ; 

Either the telename of the author identified by the 
responder, if the latter is assigned or such a constraint 
is imposed, or a nil, otherwise. 

10 maiorEdition : 

Integer | Nil; 

Either the number of the major edition identified by 
the responder, if the latter is assigned or such a 
constraint is imposed, or a nil, otherwise. 

15 minorEdit ion : 

Integer ] Nil; 

Either the number of the minor edition identified by 
the responder, if the latter is assigned or such a 
constraint is imposed, or a nil, otherwise. 

20 title : 

Identifier ! ; 

The identifier of the title the respcnder identifies. 

Adaptations 
isAf ter 

25 One citation is after another iff their "author" 

attributes are peers, their "title" attributes equal, and 
the first citation's "na j orEdi t ion" attribute is after 
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the second citation's M ma jcrEdit ion" attribute or the 
"majorEdition" attributes of both citations are equal and 
the first citation's "minorEdit ion" attribute is after the 
second citation' s. 

5 isBef ore 

One citation is before another iff their "author" 
attributes are peers, their "title" attributes equal, and 
the first citation's "majorEdition" attribute is before 
the second citation's "majorEdition" attribute or the 
10 M majorEdition M attributes of both citations are equal and 
the first citation's "minorEdition" attribute is before 
the second citation's. 

is Equal 

Two citations are equal iff their "author" attributes 
15 are peers and their other native attributes are equal. 

4 . 13 Cited 
Cited 

Class 

Cited : 

20 abstract interface {) = (...); 

Construction 

initialize : 

unprotected op (title: Identifier!; 

majorEdition, minorEdit ion : Integer) ; 

25 Makes the respcnder's native attribute a citation 

whose "author" attribute is the current process' assigned 
telename and whose other attributes are the like-named 
arguments (arguments "majorEdition", "minor-Edition 11 , and 
"title" ) . 
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Public Instance Attributes 
cit at ion : 

readonly protected Citation; 

The responder's assigned citation. 

5 4.14 Class 

Cbj ect (Referenced) 

• Class (Cited & Interchanged) 

Class 

Class : 

LO sealed interface (Object, Cited, Interchanged) = 

(-..); 

Construction 

initialize : 
unprotected op {) 
.5 throws FeatureUnavailable; 

Throws an exception ("FeatureUnavailable") . 
Note: A class is created using operation 

"makeCIasses", not operation "new". 

Public Instance Operations 
0 convert : 

sealed cp (source: protected Object) copied Object 
throws ConversionUnavailable ; 

Returns either the instance of the responder produced 
by converting the object (argument "source") to that 
5 class, if the object is not already an instance of that 
class, or a copy of the object, otherwise. 

The operation looks for a conversion method first in 
the source class and then, failing that, in the 
destination class. An exception is thrown if the object 
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cannot be converted as requested 
{ ConversionQnavailahle " ) . 

£Iote: The two steps permit either the source or the 

destination class, whichever was defined later, 
5 to implement the method for a particular 

conversion , 

islnstance : 

sealed op {instance: protected Object) 3oolean; 

Returns an indication of whether the object (argument 
0 "instance") is an instance of the responder. 

i sMember : 

sealed op (member: protected Object) Boolean; 



Returns an indication of whether the object (argument 
"member" ) is an interface, but not necessarily an 
5 implementation, member of the responder. 

isSubclass : 

sealed op (subclass: Class) Boolean; 



Returns an indication of whether the class (argument 
"subclass") is a subclass of the responder. 

0 new : 

sealed op (parameters: Object ...) Object 

throws ClassAbstract , Exception, Obj ectUninitialized; 

Returns the new instance of the responder determined 
by the initialization parameters (argument "parameters"). 
5 The signature above notwithstanding, the operation's 

signature is that of operation "initialize" as defined by 
the responder. 
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20 



25 



30 



An exception is thrown if the responder is abstract 
{ "ClassAbstract " ) , a class-specific problem is encountered 
("Exception"), cr the potential object uses its own 
features ( "Ob jectUninit ial izec" ) . 

5 4.15 Class Definition 
Object (Referenced) 
• Class Definition 

Class 

ClassDef inition : 
10 sealed interface = (...); 

Construction 

initial ize : 
unprotected op ( 

title : Identifier ! ; 
15 majorEdition, minorEdit ion : Integer; 

interface : Interface ; 

implementation: Implementation j Nil ) ; 



Makes the responder' s native attributes the 
like-named arguments (arguments "implementation", 
35 20 " interface" , "majorEdition", "minorEdition" , and "title") 

Public Instance Attributes 
implementation : 
40 Implementation j Nil ; 

Either the implementation of the class the responder 
25 defines, if there is an implementation, or a nil, 

45 

otherwise . 

interface : 
so Interface; 
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The interface of the class the respcnder defines. 

mai credit ion : 
Integer; 

The "ma j orEdition " attribute of the assigned citati 
5 of the class the responder defines. 

minorEdit ion : 
Integer; 

The "minorEciticn" attribute of the assigned citati. 
of the class the responder defines. 

10 title: 

Ident if ier ! ,- 

The "title" attribute of the assigned citation of z 
class the responder defines. 

Public Instance Operations 
15 makeClasses: 

cp {definitions: protected ClassDef inition . ..} 

Lexicon [Class] 
throws Class Exception; 

Returns a lexicon of the classes the responder and 
20 the other class definitions (argument "definitions") 

define collectively. Each value is the class whose title 
equals the associated key. 

A citation is assigned to each class as follows. Th 
assigned citation's "author" attribute is the current 
25 process' assigned telename. The assigned citation's othe 
attributes are as defined by the class' class definition. 

An exception is thrown if "he classes cannot be 
created ( "ClassExcept ion" ) . 
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Adaptations 
is Saual 

Two class definitions are equal according to thei: 
native attributes. 

5 4.16 Class Exception 
Object (Referenced) 

• Exception (Unchanged) 

• • Programming Exception 

• • • Class Exception 



10 Class 
20 ClassException : 

abstract interface (ProgrammingExcept ion) 



Subclasses 

ClassSealed: 
15 interface (ClassException) = (); 

A proposed new class has an immediate superclass that 
is sealed. 

ClassUndef ined : 

interface (ClassException) = (}; 

20 A proposed new class uses an undefined class 

identifier . 

FeatureRedef ined : 

interface (ClassException) = () ; 

A proposed new class and one of its interface 
25 superclasses have native features denoted by the same 
identifier . 

FeatureSealed : 
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interface (ClassExcepc ion) = (); 

A proposed new class implements a feature sealed by 
one cf the class' interface superclasses. 

FeatureUndef ined : 
5 interface (ClassSxcept i~n) = { } ; 

A proposed new class uses an undefined feature 
identifier . 

MixinDisal lowed : 

interface (ClassExcepc ion) = (); 

10 A proposed new class uses a mix-in where a flavor is 

required . 

Superclasses Invalid : 

interface (ClassExcept ion) = (} ; 

A proposed new class has immediate superclasses that 
15 are inconsistent. 

4.17 Collection 
Object (Referenced) 
• Collect ion 

Class 
:0 Collection : 

interface [itemClass: Class] = (...); 

Parameterized by the class (argument " itemClass " ) of 
which each item of each member of the subject class is 
itself a member. 

5 Construction 
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initialize : 

unprotected op (items: itemClass ...) throws 
Itemlnvalid; 

Makes the responder's items the objects (argument 
5 "items") . 

An exception is thrown if a proposed item is invalid 
{ " Itemlnvalid" ] . 

Public Instance Attributes 
length : 
-0 readonly Integer; 

The responder's length. 

Public Instance Operations 
clear : 

unprotected op (); 

5 Removes from the responder 

items . 

Note : The operation reduces 

zero . 

examine : 

0 °P (item: protected itemClass) itemClass | Nil ; 

Either leaves in the responder and returns an item 
that equals the object (argument "item"), if there is at 
least one such item, or returns a nil, otherwise. If 
there are several such items, the one selected is 
5 undefined. 

exclude : 

unprotected op (item: protected itemClass) 
itemClass J Nil ; 



and discards all of its 
the responder's length to 
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Either excludes from the responder and returns an 
item that equals the object (argument "item"), if there i 
at least one such item, or returns a nil, otherwise. If 
there are several such items, the one selected is 
5 undefined. 

include ; 

unprotected op (item: itemClass ) throws I temlnvai id ; 

Includes the object (argument "item") in the 
responder as a new item. 
0 An exception is thrown if the proposed item is 

invalid as such (" I temlnvai id" ) . 



scream : 

op {} copied Stream [itemClass] ; 



Returns a stream whose items are those of the 
.5 responder. A subclass of class "Collection" can define 
the order in which the stream produces the responder' s 
items, but class "Collection" leaves z \-» order undefined. 

If the responder is changed after the stream is 
created, the stream produces newly included items iff the 
0 stream would not have produced them earlier and does not 
produce newly excluded items unless the stream did so 
earlier . 

Note; The subclass of class "Stream" of which the 

stream is an instance is undefined. 

5 Adaptations 
isEqual 

Two collections are equal iff their lengths are equal 
and their items can be paired so as to make the items in 
each pair equal. A subclass of Collection can narrow, but 
0 not broaden, this definition of equality. 
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4 . 18 Collection Exception 
Object (Referenced) 
5 • Exception (Unchanged) 

• • Programming Exception 
5 • • • Collection Exception 

10 

Class 

CollectionException : 

abstract interface ( ProgrammingExcept ion) = {); 

15 

Subclasses 
10 I temDupl icated : 

interface (CollectionException) = (); 

20 

One proposed item of a set equals another, 

25 Itemlnvalid : 

interface (CollectionException) = (); 

15 A collection's proposed item does not satisfy the 

30 

collection' s constraint . 

KeyDupl icated ; 
35 interface (Collect icnExcept ion} = 0; 

One proposed key of a dictionary equals another. 

40 

2 0 Key In valid : 

interface (CollectionException) = 0; 

45 A dictionary's proposed key does not meet the 

dictionary's constraint, or an object purporting to equal 
a key in a dictionary does not. 

50 2 5 ObiectsUnpaired : 

interface (CollectionException) = (); 
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Supposedly paired keys and values of a dictionary a 
odd in number. 

Posit ionlnval id : 

interface (Collect ionExcept ion) = ( ) ; 

5 An integer purporting to equal a position in a list 

or a procedure does not. 

StackDepleted : 

interface (Collect ionExcept ion) = 0; 

The length of a stack prevents the stack's 
0 manipulation as requested. 

4.19 Constrained 
Constrained 

Class 

Constrained : 
5 abstract interface () = (...); 

Construction 

initialize : 

unprotected op (constraint: copied Const raint j Nil ) ; 

Makes the responder's native attribute either the 
C constraint (argument "constraint") , if not a nil, or one 
with nil initialization parameters, otherwise. 

Public Instance Attributes 
constraint : 

readonly protected Constraint; 

5 The constraint upon nominated properties of the 

responder . 
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4.20 Constrained Dictionary 
Ob j ect (Referenced] 

• Collection 

• • Set 

5 • • • Dictionary 

• • • • Constrained Dictionary (Constrained) 



Class 

ConstrainedDict ionary : 

interface [keyClass, vaiueClass: Classj 
0 (Dictionary [keyClass, vaiueClass] , Constrained) 

= (..J; 

Parameterized by the classes of which the key 
(argument "keyClass") and the value (argument 
"vaiueClass") of each item of each member of the subject 
5 class are themselves members. 



Construct ion 

ini t ialize : 

unprotected op (constraint: copied Constraint; 
keysAndValues : Object . . . 
0 /* key: keyClass; value: vaiueClass */5 

throws XeyDuplicated, Keylnvalid, 
ObjectsUnpaired; 



Makes the responder's items associations between the 
key- value pairs (argument "keysAndValues") and the 
5 responder's "constraint" attribute the constraint 
(argument "constraint"). 

An exception is thrown if two proposed keys are equal 
( "KeyDuplicated" ) , a proposed key is invalid as such 
( "Keylnvalid" ) , or the number of objects is odd 
0 ("ObjectsUnpaired") . 
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Adaptations 
add 

Only a key satisfying the constraint will be 
included . 

constraint 

The constraint is upon the keys. 



15 include 

Only a key satisfying the constraint will be 
included . 
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10 rekey 

Only a key satisfying the constraint: will be 
included . 

set 

Only a key satisfying the constraint will be 
15 included. 

4 ■ 21 Constrained List 
Object: (Referenced) 

• Collection 

• • List (Ordered) 

2.0 • • • Constrained List (Constrained) 

Class 

ConstrainedList : 

interface [itemClass: Class] 

(List [itemClass] , Constrained) = (...); 

25 Parameterized by the class (argument "itemClass") of 

which each item of each member of the subject class is 
itself a member. 
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Construction 

initialize : 

unprotected op (constraint: copied Constraint; 
items : itemClass . . . ) 
5 throws Itemlnvalid; 

Makes the responder's items the objects (argument 
"items"), their positions increasing from left to right, 
and the responder's "constraint" attribute the constraint 
(argument "constraint") . 
0 An exception is thrown if a proposed item is invalid 

("Itemlnvalid") . 

Adaptations 
add 

Only an object satisfying the constraint will be 
5 included. 

constraint 

The constraint is upon the items. 
include 

Only an object satisfying the constraint will be 
0 included. 

4.22 Constrained Set 
Obj ect (Referenced) 

• Collection 

• • Set (Verified) 

5 • • • Constrained Set (Constrained) 

Class 

ConstrainedSet : 

interface [itemClass : Class] 

(Set [itemClass], Constrained) = (...); 
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Parameterized by the class {argument " itemClass " ) of 
which each item of each member of the subject class is 
itself a member. 

Construction 
5 initialize : 

unprotected op (constraint: copied Constraint; 
items: itemClass . . 

throws ItemDuplicated, Itemlnvalid; 



Makes the responder's items the objects (argument 
10 "items") and the responder's constraint attribute the 
20 constraint (argument "constraint"). 

An exception is thrown if two proposed items are 
equal ( n ItemDuplicated" ) or a proposed item is invalid as 
such ( " Itemlnvalid" ) . 

25 

15 Adaptations 

constraint 

30 The constraint is upon the items. 

include 

Only an object satisfying the constraint will be 



20 included. 

4.23 Constraint 
Object (Referenced) 
• Constraint 



Class 

45 2 5 Constraint : 

interface = (...); 



Construction 

initialize^ 
unprotected op 
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(ciassld, passage: Identifier! J Nil ; 
isOptional , is Instance : Boolean ] Nil) 
throws Passage I nval id; 

Makes the responder's "ofClass" attribute a nil and 
5 the responder's other native attributes the like-named 
arguments (arguments "ciassld" , " islnstance " , 
"isOptional", and "passage"). If an argument is a nil, 
however, the corresponding attribute is made the 
identifier of class "Object", "false", "false", or 
10 "byRef" , respectively. 

An exception is thrown if the proposed passage is 
invalid as such (" Passage Invalid" ) . 



Public Instance Attributes 
ciassld : 
25 15 Identifier I ; 



The identifier of the class of which the responder's 
subject shall be a member. The identifier is interpreted 
according to the "vocabulary" attribute of the interface 
or implementation -nan provides the resDonder's context. 



35 2C islnstance : 

Boolean ; 



Whether the responder's subject shall be an instance, 
not just a member, of the class that the "ciassld" 
attribute denotes. 



2 5 isOptional : 

45 Boolean; 

Whether the responder's subject is permitted to be a 
nil, the "ciassld" attribute notwithstanding. 
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Of Cla3S : 

readonly Class | Nil; 

If noc a nil, the class of w 
subject shall be a mender. 

5 passage : 

Identifier ! 

throws Passage Inval id ; 

The identifier denoting how 
shall be passed. 
0 An exception is thrown if th 

invalid as such ( "Passagelnvalid' : 

Adaptations 
isEqual 

Two constraints are equal ac- 
5 attributes. 

4 . 24 Contact 
Object (Referenced) 
• Contact 

Class 
0 Contact : 

interface = (...); 

Construction 

initialize : 

unprotected op (subject: Pro^. 
5 subjectNotes : Object j Ni." 

Makes the responder's "sub jet 
attributes the like -named argumen- 
and "subjectNotes" , respectively* 
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other native attributes either descriptive of the subject, 
if the "subject" attribute is a process, cr a nil, 
otherwise . 

Public Instance Attributes 
5 subi ect : 

Process | Nil ; 

The responder's subject or a nil. 
subiectClass : 

readonly protected Citat ion j Nil ; 

10 Either the assigned citation of the class, which is a 

subclass of class "Agent" or class "Place", of which the 
responder's subject is an instance, if the "subject" 
attribute is a process, cr either that class or a nil, if 
the "subject" attribute is a nil. 

15 subi eccName : 

readonly protected Telename | Nil ; 

Either the assigned telename of the responder's 
subject, if the "subject" attribute is a process, [or that 
telename] or a nil, otherwise. 

2 0 subiectNotes : 

Object j Nil ; 

An object maintained by the responder's observer. 

Adaptations 
isEoual 

25 Two contacts are equal according to their 

"subject Name" attributes . 
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4 . 25 Contacted 
Contacted 

Class 

Contacted : 
5 abstract interface () = (...); 

Construction 

initialize 

Clears the responder's "contacts" attribute. 



Private Instance Attributes 
20 10 contacts : 

readonly Set [Contact] ; 



The set of contacts that the responder maintains. 



4.26 Dictionary 
Cbi ect (Referenced) 
30 15 • Collection 
• Set 
• • • Diet ionarv 



Class 

Dictionary : 

20 interface [keyClass, valueClass: Class] 

(Set [Association [keyClass, valueClass]]) = 

<-..); 

Parameterized by the classes of which the key 
(argument " keyClass " ) and the v- . -e (argument 
25 "valueClass") of each item of each member of the subject 
class are themselves members. 

Construction 

initialize 
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unprotected op (keysAndValues : Object ... 

/* key: keyClass; value: valueClass */) 
throws KeyDuplicated, Key Invalid, 
ObjectsUnpaired; 

5 Makes the responder' s icems associations between the 

key-value pairs (argument "keysAndValues"). 

An exception is thrown if two proposed keys are equal 
("KeyDuplicated"), a proposed key is invalid as such 
( "Keylnvalid" ) , or the number of objects is odd 

0 ("ObjectsUnpaired"). 

Public Instance Coerations 
add: 

unprotected op (key: keyClass ; value: valueClass) 
throws Keylnvalid; 

5 Includes in the responder a new association, one that 

involves the first object [argument "key") as the 
associations' key and the second (argument "value") as the 
association's value. 

An exception is thrown if the proposed key is invalid 

0 as such or equals the key in an association that the 
responder already includes ("Keylnvalid"). 

drop : 

unprotected op (key: protected keyClass) valueClass 
throws Key Inval id ; 

5 Excludes from the responder and discards the 

association whose key equals the object (argument "key"), 
and returns the association's value. An exception is 
thrown if the asserted key is invalid as such 
( "Keylnvalid" ) . 

0 find: 
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op (value: protected valueCIass) keyClass j Nil ; 

Leaves in the respcnder the association whose value 
equals the object (argument "value"), and returns the 
association's key. If the responder includes several such 
5 associations, the one selected is undefined. If the 
responder includes none, a nil is returned. 

get : 

op {key: protected keyClass) valueCIass 
throws Keylnvalid; 

10 Leaves in the responder the association whose key 

equals the object (argument "key"), and returns the 
association's value. 

An exception is thrown if the asserted key is invalid 
as such ("Keylnvalid"). 

15 rekev: 

unprotected op (currentKey: protected keyClass; 

newKey: keyClass) 
throws Keylnvalid; 

Leaves in the responder the association whose key 
20 equals the first object (argument "currentKey"), discards 
that association's key, and substitutes for that key the 
second object (argument "newKey"). The operation achieves 
this as if by means of operations "drop" and "add". 

An exception is thrown if the asserted or proposed 
25 key is invalid as such or the latter equals the key in an 
association that the responder already includes 
("Keylnvalid") . 



set : 



unprotected op (key: protected keyClass; value: 
30 valueCIass) 
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throws Key Invalid ; 

If the responder includes an association whose key 
equals the first cbject {argument "key"), substitutes for 
that association's value the second object {argument 
5 "value"). Otherwise, includes in the responder a new 
association, one that involves the first object (argument 
"key") as the association's key and the second (argument 
"value") as the association's value. 

An exception is thrown if the proposed key is invalid 
0 as such ( " Keylnvalid" } . 

transpose : 

unprotected op (keyl, key2 : protected keyClass) 
throws Xeylnvalid; 

Transposes the responder' s values for the two keys 
5 (arguments "keyl" and "key2"). 

An exception is thrown if an asserted key is invalid 
as such (" Key Invalid" ) . 

Adaptations 
include 

0 Only an association is included. An association is 

included as a new item after excluding and discarding any 
existing item equal to the association. 

is Equal 

Two dictionaries are equal only if their like-keyed 
5 values are equal . 

4.27 Exception 

Object (Referenced) 

• Exception (Unchanged) 

Class 
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Exception : 

abstract interface (Object, Unchanged) = (...),- 

Public Instance Operations 
throw : 

sealed op ( ) ; 

Finishes the current method's performance by causing 
the method to fail because of the responder. 

Adaptations 
is Equal 

Two exceptions are equal iff they are instances of 
the same class. 

4 -28 Executed 
Executed 

Class 

Executed : 

abstract interface {) = (); 

This class is sealed. 

Public Instance Operations 
catch: 

sealed op (exception: Class) Exception | Nil 
throws Except ion ; 

Performs the responder, returning either a nil, if 
the responder succeeds, or the exception causing the 
responder to fail, if the exception is a member of the 
supplied class (argument "exception"). The responder gets 
access to the requester's frame and properties, rather 
than the responder' s. 
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An exception is thrown if the responder throws an 
exception that is not a member of the supplied class 
( "Exception" ) . 

Note: The class should be Exception or a subclass 

5 thereof. 

do: 

sealed op () 

throws Exception ; 

Performs the responder. The responder gets access 
0 the requester's frame and properties, rather than the 
responder' s . 

An exception is thrown if the responder does so 
( "Exception" ) . 

either : 

5 sealed op (false: Executed; precondition: Boolean) 

throws Exception; 

Performs either the responder, if the precondition 
(argument "precondition") is true, or the executed objec 
(argument "false"), otherwise. The selected executed 
G object gets access to the requester's frame and 
properties, not the responder' s. 

An exception is thrown if the selected executed 
object does so ("Exception"). 

if: 

5 sealed cp (precondition: Boolean) 

throws Except ion ; 

Performs the responder iff the precondition (argumen 
"precondition") is "true". The responder gets access to 
the requester's frame and properties, not its own . 
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An exception is thrown if the responder does so 
( "Exception" ) . 

loop : 

sealed op ( ) 

throws Except ion ; 

Performs the respcnder an indefinite number of tines 
throwing the exception, rather than proceeding, if the 
respcnder ever fails. The responder gets access to the 
requester's frame and properties, rather than the' 
respcnder' s . 

An exception is thrown if the responder does so 
( "Exception" ) . 

repeat : 

sealed op (repetitions: Integer) 
throws Exception; 

Performs the responder the requested number of times 
(argument "repetitions"), throwing the exception, rather 
than proceeding, if the responder ever fails. If the 
integer is negative, the operation has no effect. The 
responder gets access to the requester's frame and 
properties, rather than the responder' s. 

Before each performance of the responder, the 
operation pushes onto the stack an integer that is one 
plus the number of prior performances. 

An exception is thrown if the responder does so 
( "Exception") . 

Note: The operation pops none of the integers the 

operation pushes onto the stack. 

while : 

sealed op (precondition: Executed) 

throws Exception, Resul t Invalid, ResultMissing f - 
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Repeatedly performs the executed object (argument 
"precondition"), pops a boolean from the stack, and, iff 
the boolean is true, performs the responder. If the 
boolean is ever false, the operation succeeds. If either 

5 executed object ever fails, the operation throws the 

exception, rather than proceed. The executed objects are 
given access to the requester's frame and properties, 
rather than the responder' s. 

An exception is thrown if either executed object does 

0 so ("Exception"), the object that would have been popped 
is not a boolean { "Result Invalid" ) , or there is no object 
on the stack to be popped then ( "ResultMissing " ) . 

4.29 Execution Exception 
Ob j ect (Referenced) 
5 • Exception (Unchanged) 

• • Programming Exception 

• • • Kernel Exception 

• • • • Execution Excep tion 

Class 

0 Execut ionSxceotion : 

abstract interface (KernelExcept ion ) = (); 

Subclasses 

Argument Inval id : 

interface (ExecutionExcepticn) = (),- 

5 An argument does not satisfy the argument's 

constraint . 

ArgumentMissing : 

interface (ExecutionExcept ion) = (); 
An argument is not on the stack. 
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AttributeReadCnlv : 

interface (Execut ionExcept ion) = () ; 

An attribute is read-only, and thus cannot be sec. 

ClassUnavailable : 
5 interface (ExecutionException) = (); 

A class is in neither attribute "privateClasses ,f of 
the current process nor attribute "publ icClasses " of the 
current place. 

Escalat ionlnvalid : 
0 interface (ExecutionException) = (); 

A feature is escalated improperly. 

FeatureUnavailable : 

interface (ExecutionException) = (); 

An identifier does not denote an accessible feature 
5 of the responder. 

InternalExcept ion : 

interface (Execu: ionExcept ion) = () ; 

An Engine fails to fully implement the Instruction 

Set . 

0 ProcertvUndef ined : 

interface (ExecutionException) = (); 

An identifier does not denote a property accessible 
to the current method. 

Reference Protected : 
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interface (ExecutionException) = () ; 

A reference to an object prevents the object's 
modification . 

Re f erenceVoid : 
5 interface (ExecutionExcept ion) = {); 

A reference is void. 

ResponderMissinc : 

interface (ExecutionException) = 0; 

A feature is requested when the stack is cleared 

.0 Resultlnvalid: 

interface (ExecutionException) = () ; 

A result does not satisfy the result's constrain 

ResultMissing : 

interface (ExecutionException) = (); 
5 A result is not on the stack. 

VariableUndef ined : 

interface (ExecutionException) = ( ) ; 

An identifier does not denote a variable. 

4 .30 Feature 
0 Object (Referenced) 
• Feature 

Class 

Feature : 
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abstract interface = (...); 

This class is sealed. 

Construction 

initialize : 
5 unprotected op ( 

isPublic : Boolean ( Nil ; 

exceptions: Set [Identifier!] jNil) ; 

Makes the responder's native attributes the 
like-named arguments (arguments "exceptions" and 
,0 "isPublic") . If an argument is a nil, however, the 
corresponding attribute is cleared or made "false", 
respect ively . 

Public Instance Attributes 
exceptions : 
5 Set [Identifier!]; 

The identifiers denoting the classes of which the 
exceptions thrown by the feature the responder defines are 
members. The identifiers are interpreted according to the 
"vocabulary" attribute of the interface that includes the 
0 responder . 

isPublic : 
Boolean; 

Whether the feature that the responder defines is 
public, i.e., not private. 

5 4.31 Hashed 
Hashed 
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Hashed : 

abstract interface () = (...) 

Public Instance Attributes 
5 hash: 

abstract readonly Integer; 

The responder's hash. 



4.32 Identifier 
Object (Referenced) 
20 10 • Primitive (Executed & Unchanged) 

• • Identifier (Ordered) 



50 



Class 

I dentifier : 

sealed interface (Primitive, Ordered) = () ; 

15 Adaptations 
isAf ter 

One identifier is after another according to 
their texts. 

isBef ore 

20 One identifier is before another according to their 

texts . 

isEauai 

Two identifiers are equal according to their texts. 
■ Conversions 

25 String 

A string that is valid as an identifier's text 
produces that identifier. 
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4.33 Implerrsentat ion 
Object (Referenced) 
• Implementation 

Class 

Implementation : 

sealed interface = (...) 

Construction 

initialize : 



unprotected op (superclasses: List [Identifier !] |Nil j 
10 vocabulary: Lexicon [Citation] ! Nil ; 

20 properties: List [ Identifier !] | Nil ; 

instanceMethods , setMethods , classMethods , 
fromMethcds, toMethcds : Lexicon [Method] j Nil) ; 



Makes the respcnder's native attributes the 
15 like-named arguments (arguments "classMethods", 
"f romMethods" , "instanceMethods" , "properties" , 
"setMethods", "superclasses", "toMethods", and 
"vocabulary"). If an argument is a nil but the 
corresponding attribute is not permitted to be a nil, 
20 however, the corresponding attribute is cleared. 

Public Instance Attributes 
classMethods : 
Lexicon [Method] ,- 

Methods- -for class operations, including operation 
25 "aGet", other than operation "aSet" which is 

disallowed- -nat ive to a class incorporating the responder. 
Each value is a method for performing the operation the 
associated key denotes. 

f romMethods : 
30 Lexicon [Method] ; 
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Methods- -for converting from other classes - -nat ive tc 
a class incorporating the responder. Each value is a 
method fcr converting from the class the associated key 
denotes . 

Note : In an implementation of class "Dictionary", if 

the class identified is class "List", the 
conversion is that whose responder is class 
"Dictionary" and whose signature is "List: cp 
disc: protected List) Dictionary". 

instanceMethods : 
Lexicon [Method] ; 

Methods- -for instance operations, including operation 
"aGet", other than operation "ccSet" (see attribute 
"secMethods" )- -native to a class incorporating the 
responder. Each value is a method for performing the 
operation the associated key denotes. 

properties : 

List [Identifier!] ; 

The identifiers of properties native to a class 
incorporating the responder. Their order has no 
significance in the interpretation of the disclosed 
instruction set. However, the order of the properties is 
significant in the Encoding Rules disclosed in Appendix B 
of this disclosure. 

setMethods : 
Lexicon [Method] ; 

Methods- -for "aSet" instance operations - -nat ive to a 
class incorporating the responder. Each value is a method 
for performing the operation the associated key denotes. 
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superclasses : 

List [Identifier!] ] Nil ; 

Either the identifiers of the implementation 
immediate superclasses of a class incorporating the 
5 responder, if they differ from the class' interface 

immediate superclasses, or a nil, otherwise. The classes' 
canonical order is that of their identifiers; the last 
class shall be a flavor. 

toMethods : 
0 Lexicon (Method] ; 

Methcds--for converting to ether classes-native to a' 
class incorporating the responder. Each value is a method 
for converting to the class the associated key denotes. 
Mote: In an implementation of class "Diet ionary" , if 

5 the class identified is class "List", the 

conversion is that whose responder is a 
dictionary and whose signature is "List: op () 
List" . 

vocabulary : 
0 Lexicon [Citation] j Nil ; 

Either the user-defined classes to which the 
— sponder refers, if they are not those to which the 

...ass' interface refers, or a nil, otherwise. Each value 
is a citation to the class the associated key denotes. 
The attribute guides the interpretation of the responder' s 
"fromMethods" , "superclasses", and "toMethods" attributes 
(and no others) . 

Adaptations 
isEaual 
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Two implementations are equal according to theii 
native attributes . 

4.34 Integer 

Obj ect (Referenced) 

• Primitive (Executed & Unchanged) 

• • Number (Ordered) 

• • • Integer 

Class 

Integer : 

sealed interface (Number) ={...); 

Public Instance Operations 
modulus : 

op (divisor: Integer) Integer 
throws DivisionByZero; 

Returns the arithmetic remainder of the responde 
the dividend, and the integer (argument "divisor")/ t 
divisor. The former's sign determines the result's. 

An exception is thrown if the divisor is zero 
■["DivisionByZero"} . 

guotient : 

op (divisor: Integer) Integer 
throws DivisionByZero; 

Returns the arithmetic quotient of the respcnder 
dividend, and the integer (argument "divisor"), the 
divisor . 

An exception is thrown if the divisor is zero 
("DivisionByZero") . 
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Adaptations 
abs 

The result is an integer. 
add 

The result is a real if the argument is a real, an 
integer if an integer. 

divide 

The result is a real if the argument is a real, an 
integer if the argument is an integer and the result, would 
be exact, and a real, otherwise. 

multiply 

Same as described above f :r operation "add" . 
negate 

The result is an integer. 
subtract 

Same as described above for operation "add" . 

Conversions 
Bit 

The bits "zero" and "one" produce zero and one, 
respectively . 

3itString 

A bit string that can be produced by converting some 
integer produces the integer. 

Boolean 

The booleans "false" and "true" produce zero and one, 
respectively. 

Character 
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A character produces the integer in [0, 55535] that 
is the character's Unicode cede. 

Octet 

An octet produces the result of first 
5 octet to an octet string, and then convert i 
string to an integer. 

QctetSt ring 

An octet string that can be produced by converting 
some integer produces the integer. 

0 Real 

A real produces the integer that results from 
performing operation "truncate" . 

String 

A string that obeys the syntactic rules for the 
5 "Integer" token in Character Telescript produces the 
corresponding integer. 

4.35 Interchanged 

Unchanged 

• Interchanged 

0 Class 

Interchanged : 

abstract interface (Unchanged) = (...}; 

Public Instance Attributes 
digest : 

5 abstract readonly protected Object } Nil ; 

Either the digest of the responder, if the responder, 
i.e., this particular instance of the class, is 
interchangeable, or a nil, otherwise. 



converting the 
ng the octet 
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4.36 Interface 
Object (Referenced) 
• Interface 

Class 
5 Interface : 

sealed interface = (...); 

Construction 

initialize : 

unprotected op (superclasses: List [ Ident if ier ! ] j Nil 
vocabulary: Lexicon [Citation] jNil; 
instanceFeatures : Lexicon (Feature] j Nil ; 
sealedlnstanceFeatures : Set [Identifier!] jNil; 
classFeatures : Lexicon [Feature] jNil; 
sealedClassFeatures : Set [Identifier'] jNil; 
15 isAbstract: Boolean J Nil) ; 

Makes the responder's native attributes the 
like-named arguments (arguments "classFeatures", 
"instanceFeatures" , "isAbstract" , "sealedClassFeatures" , 
"sealedlnstanceFeatures" , "superclasses" , and 

20 "vocabulary"). If the corresponding argument is a nil, 
however, attribute "isAbstract" is made "false", attribute 
"superclasses" is made a list of the identifier of class 
"Object" alone, or the attribute is cleared if the 
attribute is other than actribrutes "isAbstract" and 

25 "superclasses'* . 

Public Instance Attributes 
classFeatures : 
Lexicon [Feature] / 

The class features native to a class ir -orporating 
30 the responder. Each value is the feature d-mition of 
the feature the associated key denotes. 
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ir.stanceFeatures : 
Lexicon [Feature] ; 



The instance features native to a class incorporating 
the responder. Each value is the feature definition of 
the feature the associated key denotes. 



isAbstract : 
3ooiean; 



Whether a class incorporating the responder is 
abstract . 



sealedClassFeatures : 
Set [Identifier!]; 



The identifiers of the class features that are either 
native to or inherited by a class incorporating the 
responder, and that are sealed by that class. 



sealedlnstanceFeatures : 
Set [Identifier! ] ; 



The identifiers of the i 
either native to or inherited 
responder, and that are seale 

superclasses : 

List [identifier!] ; 



nstance features that are 

by a class incorporating the 
d by that class. 



The identifiers of the interface immediate 
superclasses of a class incorporating the responder. The 
classes' canonical order is that of their identifiers; the 
last class shall be a flavor. 

vocabulary : 
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Lexicon [Citation] ; 



The user-defined classes to which the responder 
refers. Each value is a citation to the class the 
associated key denotes. The attribute guides the 
5 interpretation of the responder' s "superclasses" 
10 attribute and no others. 



Adaptat ions 
isSgual 

15 

Two interfaces are equal according to their native 
10 attributes. 



4-37 Kernel Exception 
Obj ect (Referenced) 

• Exception (Unchanged) 

• • Programming Exception 
15 • • • Kernel Exception 
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Class 

KernelException: 

abstract interface (ProgrammingExcept ion) = () ; 

Subclasses 
2 0 ClassAbstract : 

interface (KernelException) = (); 

An object's proposed class is abstract. 



ConversionUnavailable : 

interface (KernelException) = () ; 

An object's proposed conversion is undefined. 
CcpvUnavailable : 

interface (KernelException) = (] ; 
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An object's property cannot be copied. 
LoooMissina : 

interface (KernelException) = {); 

A lcop is broken or continued where no loop exists. 



15 



MarkMissing : 

interface (KernelException) = (); 



A stack's items do not include a mark. 



20 



ObiectUninitialized : 

interface (KernelException) = (); 



25 



10 An object attempts to use one of its features be: 

escalating operation "initialize". 
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Passagelnvalid : 

interface (KernelException) = (}; 

An object's proposed passage is invalid. 



35 



IS SelectorDupl icated : 

interface (KernelException) = () 
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Two selectors are equal. 

4 - 38 Lexicon 

Object (Referenced) 
Collection 

• Set 

• • Dictionary 

• • • Constrained Dictionary (Constrained) 

• • • • Lexicon 
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Class 

Lexicon : 

interface [valueCiass: Class] 

(ConstrainedDict ionary [Identifier, valueCiass] ) 
S =(...); 

Parameterized by the class (argument "valueCiass") of 
which the value of each item of each member of the subject 
class is itself a member. 

Construction 
0 initialize : 

unprotected op (keysAndValues: Object ... 

/* key: Identifier!; value: valueCiass */) 
throws KeyDuplicated, Keylnvalid, 
ObjectsUnpaired; 

5 Makes the responder's items associations between the 

key-value pairs (argument "keysAndValues"). 

An exception is thrown if two proposed keys are equal 
("KeyDuplicated"), a proposed key is invalid as such 
("Keylnvalid"), or the number of objects is odd 

0 ("ObjectsUnpaired") . 

Adactat ions 

constraint 

The attribute is sealed. The attributes "of Class", 
"classld", "islnstance" , " isOptional " , and "passage" 
5 attributes are class "Identifier", the identifier of class 
"Identifier", "true", "false", and "byCopy", respectively. 

Conversions 

Dictionary 

A dictionary whose keys satisfy the constraints of a 
0 lexicon p.- "duces the lexicon. 
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4 . 39 List 

Obj ect (Referenced) 

• Collection 

• • List (Ordered) 

Class 

List : 

interface [itemClass: Class] 

(Collection [itemClass], Ordered) = (...); 

Parameterized by the class (argument "itemClass") of 
which each item of each member of the subject class is 
itself a member. 

Construction 

initialize : 

unprotected op (items: itemClass ...); 

Makes the responder's items the objects (argument 
"items"), whose positions increase from left to right. 

Public Instance Operations 
add: 

unprotected op (position: Integer; item: itemClass) 
throws Itemlnval id, Posit ionlnvalid; 

Includes the object (argument "item") in the 
responder as a new item, one whose position equals the 
integer (argument "position"), increasing by one the 
position of each item whose position is equal to or after 
that of the included item. 

An exception is thrown if the proposed item is 
invalid as such ( " Itemlnvalid" ) or the proposed position 
is invalid as such ( " Posit ionlnvalid" ) . 

drop : 
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unprotected op (position: Integer) itemClass 
throws Pos i t ion I nval id ; 

Excludes from the responder and returns the item 
whose position equals the integer (argument "position"), 
5 decreasing by one the position of each item whose positi 
is after that of the excluded item. 

An exception is thrown if the asserted position is 
invalid as such (" Posit ionlnvalid" ) . 

find: 

.0 op (initialPositicn : Integer; item: protected 

itemClass) 

Integer J Nil 
throws Pcsitionlnvalid; 

Leaves in the responder and returns the position of 
5 the item that equals the object ("item") and whose 

position is not before the integer ( " initialPosi tion" ) . 
If the responder has several such items, the one whose 
position is least is selected. If it has none, a nil is 
returned. 

0 An exception is thrown if the asserted position is 

invalid as such (" Posit ionlnval id" ) . 

get : 

op (position: Integer) itemClass 
throws Position-Invalid; 

5 Leaves in the responder and returns the item whose 

position equals the integer (argument "position") . 

An exception is thrown if the asserted position is 
invalid as such (" Posit ionlnval id" ) . 

reposition : 
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unprotected op (currentPosition, newPosition: 
Integer) 

throws Pos i t ionlnval id ; 

Changes to the second integer (argument 
5 "newPosition") the position of the responder's item whose 
position equals the first integer (argument 
"currentPosition"). The operation achieves this as if by 
means of operations "drop" and "add", except that the 
second integer is interpreted before, rather than after, 
0 operation "drop" is requested. 

An exception is thrown if an asserted position is 
invalid as such ( " Posi t ionlnval id" ) . 

set : 

unprotected op (position: Integer; item: itemClass) 
5 throws Itemlnvalid, Positionlnvalid; 

Excludes from the responder the item, if there is 
one, i.e., if the new item is not being appended, whose 
position equals the integer (argument "position"), and 
includes the object (argument ?: item") as a new item at the 
0 same position. 

An exception is thrown if the proposed item is 
invalid as such {"Itemlnvalid") or the proposed position 
is invalid as such ("Positionlnvalid") . 

transpose : 

5 unprotected op (posit ionl, position2 : Integer) 

throws Pos i t ion I n va lid; 

Transposes the responder's items that occupy the two 
positions (arguments "position! " and "posit ion2 " ) . 

An exception is thrown if an asserted position is 
invalid as such ("Positionlnvalid"). 
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Adaptations 
exclude 

The operation decreases by one the position of each 
object whose position is afrer that of the excluded item. 

5 include 

The position of the newly included item is the list's 
new length. 

isEgual 

Two lists are equal only if their like-positioned 
10 items are equal. 

scream 

The stream produces the list's items in order of 
increasing position. 

Conversions 
15 Procedure 

A procedure produces a list of the same length, each 
of whose items is a copy of the item at the same position 
in the procedure . 

4 .40 Mark 
20 Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Mark 

Class 

Mark : 

25 sealed interface (Primitive) = {); 

Adaptations 
isEgual 

Any two marks are equal . 
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4.41 Means 
Object (Referenced) 

• Means 

Class 

Means : 

abstract interface = (); 

4.42 Meeting Exception 
Object (Referenced) 

• Exception (Unchanged) 

• • Meeting Exception 

Class 

MeetingException .- 

abstract interface (Exception) = () ; 

Subclasses 

MeetinaOenied : 

interface (MeetingException) = (); 

The petitionee denies the petitioner the 

Meet inaDuplica ted : 

interface (MeetingException) = (); 

The petitioner and petitionee are the sam 
already . 

Meetinclnvalid : 

interface (MeetingException) = (); 

A contact does not represent a meeting. 

Petit ionExpired ; 

interface (MeetingException) = (); 
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The petitionee cannot be met in the time allowed. 

4.43 Meeting Place 
Object (Referenced) 

• Process (Named) 

5 • • Place (Unmoved) 

• • • Meeting Place 



Class 

15 MeetingPlace : 

abstract interface (Place) 



10 Public Instance Operations 
meet : 

unprotected op (petition: copied Petition) Contact 
throws Meet ingExcept ion, ProcessNotCurrent , 
State Improper ; 

15 Begins a meeting between the agent requesting the 

operation and the one the petition (argument "petition") 
identifies, returning a contact whose "subject" attribute 
is the latter. The latter agent must also occupy the 
responder . 

20 An exception is thrown if the meeting failed 

( "MeetingException" ) , the responder is not the current 
place ( "ProcessNotCurrent " ) , or the requester's state 
precludes "meet" ( "Statelmproper " ) . 

part : 

25 unprotected op (contact: Contact) 

throws Meetinglnvaiid, ProcessNotCurrent, 
Statelmproper; 

Ends the meeting between the agent requesting the 
operation and the subject of the contact (argument 
30 "contact"), making the contact's "subject" attribute a 
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nil, if the attribute is not a nil already. The subject 
must also occupy the responder. 

An exception is thrown if the contact is not a 
meeting's ( "Meet inglnval id" ) , the responder is not the 
5 current place { " ProcessNotCurrent " } , or the requester's 
state precludes operation "part" (" State Improper ") . 

partAll : 

unprotected op () 

throws ProcessNotCurrent, Statelmproper / 

.0 Ends all meetings that involve the requesting agent, 

and then isolates the agent . 

An exception is thrown if the responder is not the 
current place ("ProcessNotCurrent") or the requester's 
state precludes operation "partAll" ("Statelmproper"). 

5 4 .44 Method 

Object (Referenced) 
• Method 

Class 

Method : 

0 sealed interface = (...); 

Construction 

initialize : 

unprotected op {procedure: Procedure j Nil / 
variables: List [Identifier! ] j Nil ) ; 

5 Makes the responder 's native attributes the 

like-named arguments (arguments "procedure" and 
"variables"). If an argument is a nil, however, the 
corresponding attribute is cleared. 

Public Instance Attributes 
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procedure : 
Procedure; 

The responder's procedure. 

variables : 
5 List [Identifier!]; 

The identifiers of the responder's variables, their 
order having no significance with respect to the 
interpretation of the disclosed instruction set. However, 
the order of the variables is significant in the Encoding 
0 Rules described in Appendix B of this disclosure. 

Adaptations 
isEcrual 

Two methods are equal according to their native 
attributes . 

5 4.45 Miscellaneous Exception 
Object (Referenced) 

• Exception (Unchanged) 

• • Programming Exception 

• • • Mis eel laneous Exception 

0 Class 

MiscellaneousExcept ion : 

abstract interface (ProgrammingException) = (); 

Subclasses 

Patternlnvalid: 
5 interface (Miscel laneousExcept ion) = (); 

A pattern's proposed text is syntactically in error. 
Seedlnvalid : 
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interface (MiscelianeousExcept ion) = () ; 

A random stream's proposed seed is not in the 
required range. 

4.46 Modifier 
w 5 Object (Referenced) 

* Primitive (Executed & Unchanged) 

• • Modifier 
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Class 

Modifier : 

10 sealed interface (Primitive) = ()/ 

Adaptations 
isEaual 

Two modifiers are equal iff their values are the 

same . 



15 4.47 Named 
30 Named 



Class 

Named : 

abstract interface () = (...); 

2 0 Construction 

initialize 



Makes the responded s "name" attribute a newly 
assigned telename, a peer of the current process'. 

Public Ins tance Attribute 
25 name : 

sealed readonly protected Telename; 
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The responder's assigned telename. 
4.48 Nil 

Object (Referenced) 

• Primitive (Executed & Unchanged) 
5 • • Nil 

Class 

Nil : 

sealed interface (Primitive) = () ; 

Adaptations 
10 isEaual 

Any two nils are equal. 

4.49 Number 

Object (Referenced) 

• Primitive (Executed & Unchanged) 
15 • • Number (Ordered) 

Class 

Number : 

abstract interface (Primitive, Ordered) = ( 
This class is sealed. 



40 2 0 Public Instance Operaf.inng 

abs : 

abstract op () Number; 
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Returns the absolute value of the responder. 



add: 

50 25 abstract op (number: Number) Number; 
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Returns the arithmetic sum of the number ("number") 
and the respor.de r. 

ceiling : 

abstract op 0 Integer ; 

Returns the smallest integer that is arithmetically 
greater than or equal to the responder. 

divide : 

abstract op (divisor: Number) Number 
throws DivisionByZero; 

Returns the arithmetic quotient of che responder, t 
dividend, and the number (argument "divisor") , the 
divisor . 

An exception is thrcwn if the divisor is zero 
("DivisionByZero") . 

floor : 

abstract op () Integer; 

Returns the largest integer that is arithmetically 
less than or equal to the responder. 

multiply: 

abstract op (number: Number) Number; 

Returns the arithmetic product of the number 
("number") and the responder. 

negate : 

abstract op () Number; 

Returns the arithmetic negative of the responder. 
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round : 

abstract op () Integers- 
Returns the single integer that is, or one of the two 
integers that are, arithmetically nearest to the 
5 responder. 



subtract : 

15 abstract op (subtrahend: Number) Number; 

Returns the arithmetic difference between the 
responder, the minuend, and the number (argument 
20 io "subtrahend") , the subtrahend. 

truncate : 

abstract op () Integer; 



Returns the integer formed by discarding the 
responder' s fractional part so as to arithmetically 
L5 truncate the responder toward zerc. 



Adaptations 
isAf ter 

35 One number is after another iff the first is greats 

than the second. 



20 isBef ore 

One number is before another iff the first is less 
than the second. 

isEqual 

Two numbers are equal iff they are equal 
25 mathematically. 

4 . 50 Object 

Object (Referenced) 
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Object : 

abstract interface (Referenced) = (...); 



10 Construction 

5 initial ize : 

unprotected op ' ) ; 



Initializes the responder, a potential object, and 
makes the responder an object. 

finalize : 
10 unprotected op (); 

Requested as the responder is destroyed by operation 
"discard". A method for this operation finalizes the 
object with respect to the method's class. 



Public Instance Attributes 
30 15 class : 

sealed readonly Class; 



Either the class of which the responder is an 
instance, if the responder is net class "Class", or class 
"Class", if the responder is indeed class "Class". 

20 size : 

sealed readonly Integer; 

The responder' s size in octets, i.e., the approximate 
amount of storage that destroying the respender would 
reclaim . 



2 5 Public Instance Operations 
50 copy : 

sealed op () copied Object 
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throws CopyUnavailable; 

Returns either the responder, if the operation is 
requested using the only reference to zhe responder, or a 
copy of the responder, otherwise. 
5 An exception is thrown if a copy if unavailable 

("CopyUnavailable") . 

is Equal : 

op (object: protected Object) 3oolean; 

Returns an indication of whether the object (argument 
0 "object") equals the responder. 

A method shall escalade this operation if either the 
responder or the object is not a member of the class to 
which the method is native. The method native to class 
"Object" deems the two equal iff they are the same object. 

5 select : 

sealed op (associations: Object ... 

/* protected Object; Executed */) 
throws Exception, SelectcrDupiicated ; 

From the pairs of objects and executed objects 
0 (arguments "associations"), selects and performs at most 
one executed object. The one selected gets access to the 
requester's frame and properties, not the responder' s. 

If an object equals the responder, the executed 
object paired with that object is selected. Otherwise, if 
5 any object is a nil, the executed object paired with that 
object is selected. Otherwise, no executed object is 
selected. 

An exception is thrown if the selected executed 
object does so ("Exception") or two objects paired with 
0 executed objects are equal { " SeiectorDupl icated" ) 
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Internal Instance Operations 
getAt tribute : 

sealed cp (identifier: Identifier) Object 

throws ClassUnavailable, FeatureUnavailable; 

5 Returns the responder's attribute denoted by the 

identifier (argument "identifier"). The attribute folio 
the passage prescribed for the attribute. 

An exception is thrown if the class the identifier' 
qualifier denotes is absent ( ,, CiassUnavailabie ,, ) or the 
10 identifier denotes no attribute of the responder that is 
accessible to the requester ("FeatureUnavailable"). 

qetClass : 

sealed private op (identifier: Identifier!) Class 
throws ClassUnavailable; 

15 Returns the class the identifier (argument 

"identifier") denotes to the current method. 

An exception is thrown if the class is absent 
("ClassUnavailable") . 

get Property: 

sealed private op (identifier: Identifier!) Object 
throws Proper tyUnce fined; 

Returns the responder's property that is both denote 
by the identifier (argument "identifier") and native to 
the class to which the current method is native. The 
5 returned reference is protected iff the responder is 
protected . 

An exception is thrown if the identifier is invalid 
( " Proper tyUndef ined" ) . 

getVariabie : 

0 sealed private op (identifier: Identifier!) Object 
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throws VariableUndef ined; 

Returns the currenc method's variable the identifier 
(argument " identif ier *• ) denotes . 

An exception is thrown if the identifier is invalid 
{ "VariableUndef ined" ) . 

setAttribute : 

sealed unprotected op (identifier: Identifiers- 
attribute : Object) 

throws Argument Invalid, At t ributeReadOnly , 
ClassUnavailable , FeatureUnavailable ; 

Makes the object (argument "attribute") the 
responder's attribute denoted by the identifier (argument 
"identifier"). The operation first discards the attribute 
if it exists. The object follows the passage prescribed 
for the attribute. 

An exception is thrown if the object violates the 
attribute's constraint ( "Argument Invalid" ) # the attribute 
is read-only ( "AttributeReadCnly " ) , the class the 
identifier's qualifier denotes is absent 
( "ClassUnavailable" ) , or the identifier denotes no 
attribute of the respcnder that is accessible to the 
requester ( "FeatureUnavailable" ) . 

set Property : 

sealed private unprotected op (identifier: 
Identifier ! ; 

property: Object) 
throws Proper tyUnde f i ned ; 

Makes the object (argument "property") the 
responder's property that is both denoted by the 
identifier (argument "identifier") and native to the class 
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to which the current method is native. The operation 
first discards the property if the property exists. 

An exception is thrown if the identifier is invalid 
( " PropertyUndef ined" ) . 

5 setVariable : 

sealed private unprotected op (identifier: 
Identifier I ; 

va r i ab 1 e : Ob j e c t ) 
throws VariableUndef ined ; 

0 Makes the object (argument "variable") the current 

method's variable the identifier (argument "identifier") 
denotes. The operation first discards the variable if the 
variable exists . 

An exception is thrown if the identifier is invalid 

5 ( "VariableUndef ined'* ) . 

4 . 51 Octet 

Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Octet (Ordered) 

0 Class 

Octet : 

sealed interface (Primitive, Ordered) = (); 

Adaptat ions 
isAf ter 

5 One octet is after another iff two of their 

like-numbered bits are unequal a i the first octet's 
highest-numbered such bit is after the second's. 
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isBefore 

5 One octet is before another iff two of their 

like-numbered bits are unequal and the first octet's 
highest-numbered such bit is before the second's. 

10 5 isEqual 

Two octets are equal iff neither is before the other, 
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Conversions 
Bit 

A bit produces an octet whose Bit 0 equals the bit 
10 and whose Bits 1-7 are zero. 



Character 

A character whose Unicode code is an integer in [0, 
127] produces the octet that converting that integer 
25 produces . 

15 Integer 

An integer in the range of [-123, 127] produces the 
octet that forms the integer's twos' complement 
representation. Bit 7 represents -128, while Bit "n" 
represents 2\ for each "n" in the range of [0, 6} . 



2 0 Octetstrmg 

An octet string with one item produces an octet equal 
to that item. 

4.52 Octet String 
Object (Referenced) 
25 • Collection 

• • List (Ordered) 

• • • Constrained List (Constrained) 

• • • • Octet String (Executed) 

Class 
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OctetStrina : 

sealed interface (Const rainedList [Octet] , Executed) 
= (...); 



Construction 

initialize : 

unprotected op (segments: Object . . . 

/* Octet j protected OctetString! */) ; 



Makes the responder a concatenation of the segments 
(argument "segments") whose positions in the responder 
increase from left to right. 



Adaptations 

constraint 

The attribute is sealed. The attribute's "of Class" , 
"classld", " islnstance" , " isOpt ional M , and "passage" 
attributes are class "Octet", the identifier of class 
"Octet", "true", "false", and "byCopy" , respectively. 

isAf ter 

One octet string is after another as if all-zero 
octets were first prepended to the shorter octet string to 
make the shorter octet string equal in length to the 
longer octet string. 



isBef ore 

One octet string is before another as if ail-zero 
octets were first prepended to the shorter octet string to 
make the shorter octet string equal in length to the 
longer octet string. 



Conversions 
Bit 
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A bit produces the octet string that results from 
first converting the bit: to an octet, and then converting 
the octet to an octet string. 

BitStrina 

5 A bit string whose length is "n" produces an octet 

string whose length is "i" . "n" is in the range [8i, 
8i + 7] . Bit "j" of the octet at position "k" of the octet 
string either equals the bit at position (8k -j) of the ■ 
bit string, if (8k -j) sn, or is zero, otherwise. 

0 Character 

A character that can be produced by converting some 
octet string whose length is two produces that octet 
string . 

Integer 

5 An integer in the range [-2 8rM , 2 SlvI > , for an integer 

"n" and none smaller, produces an octet string whose 
length is "n" . A twos' complement representation is used, 
wherein Bit 7 of the octet whose position is one 
represents -2 8ft "\ while every other Eit "j" of the octet at 

0 position "i" in the octet string represents 2 S{n ~ l) * } . 

Octet 

An octet produces an octet string whcse only item 
equals that octet. 

String 

5 A string produces a characters token for encoding 

the string in a binary telescript. 

4.53 Operation 
Object (Referenced) 
• Feature 
0 • • Operation 
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Class 

Operation : 

sealed interface (Feature) = (...); 

Construction 

initialize : 

unprotected op (arguments: List [Constraint ] | Nil ; 
result: Constraint j Nil ; 
isPublic : Boolean | Nil ; 
exceptions: Set [Identifier!] jNil); 

Makes the responder's attributes the like-named 
arguments (arguments "arguments" , "exceptions" , 
"isPublic", and "result"). If argument "exceptions" or 
argument "isPublic" is a nil, however, the corresponding 
attribute is cleared or made "false", respectively. 

Public Instance Attributes 
arguments : 

List [Constraint] j Nil ; 

Either zhe constraints upon the zero or more 
arguments of the operation that the responder defines, if 
they do not vary in number, or a nil, otherwise, in which 
case each is passed by reference and can be any object but 
a mark. The list's first item constrains the argument on 
top of the stack. 

result : 

Constraint ] Nil ; 

Either the constraint upon the result of the 
operation that the responder defines, if the operation has 
a result, or a nil, otherwise. 

Adaptations 
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isEqual 

Two operation definitions are equal according to 
their attributes native to feature and operation 
definitions . 



10 5 4.54 Ordered 

Ordered 



Class 

Ordered : 

abstract interface () = (...); 

10 Public Instance Operations 
isAf ter : 

abstract op (object: protected Ordered) Boolean; 

25 Returns an indication of whether the responder is 

after the object (argument "object"). 
15 ^ method shall escalate this operation if either the 

responder or the object is net a member of the class to 
30 which the method is native. 

i 

isBef ore : 

abstract op (object: protected Ordered) Boolean; 



20 Returns an indication of whether the responder is 

before the object {argument "object"). 

A method shall escalate this operation if either the 
responder or the object is net a member of the class to 
which the method is native. 



45 2 5 max : 

op (object: Ordered) Ordered; 
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Returns either the responder, if the responder is 
after the object (argument "object"), or the object, 
otherwise . 

min : 

5 op (object: Ordered) Ordered; 

Returns either the responder, if the responder is 
before the object (argument "object"), or the object, 
otherwise . 

4.55 Package 
10 Object (Referenced) 

• Collection 

• • Set (Verified) 

• • • Constrained Set (Constrained) 

• • • • Package (Cited & Interchanged) 

15 Class 

Package : 

interface ( Const rainedSet [Class] , Cited, 
Interchanged) 

= (...); 

2 0 Construct ion 

init ialize : 

unprotected op (title: Identifier!; 
ma jorEdition, minorEdition : 
Integer; items : Class ...) 
25 throws ItemDuplicated, ProcessNot Peer ; 

Makes the responder' s items the classes (argument 
"items") and the responder' s "citation" attribute a 
citation whose "author" attribute is the current process' 
assigned telename and whose other attributes are the 
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like-named arguments (arguments "majorEdicion" , 
"minorEdition" , and "title"). 

An exception is thrown if two classes are equal 
( " ItemDuplicated" ) or the current process is not a class 
5 peer ( " ProcessNotPeer " ) . 

Adaptations 

constraint 

The attribute is sealed. The attribute's "of Class" 
"classld", "islnstance" , " i sOpt ionai " , and "passage" 
10 attributes are class "Class", the identifier of class 
"Class", "true", "false", and "byCopy", respectively. 

4 . 56 Pattern 

Obj ect (Referenced) 

• Pattern (Ordered) 

15 Class 

Pattern : 

interface (Object, Ordered) = (...); 

Construction 

initialize : 

20 unprotected op (text: copied String!) 

throws Patternlnvalid; 

Makes the responder's text the string (argument 
" text" ) . 

An exception is thrown if the proposed text is 
25 invalid ("Patternlnvalid"). 

Public Ins tance Operations 
find: 

op (string: protected String!; position: Integer j Nil 
List [Integer] ]N T il 
30 throws Positicnlnvalid; 
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Searches the string (argument "string") for the first 
and longest possible substring that matches the responder. 
The search begins either at the prescribed position 
(argument "position") , if an integer is supplied, or at 
5 posicion one, otherwise. 

The operation returns either a nil, if the operation 
finds no match, or a list of two integers, otherwise. in 
the latter case, the first integer is the position in the 
string of the first character in the match. The second 
0 integer is one greater than the position in the string of 
the last character in the match. 

An exception is thrown if the proposed position is 
invalid as such, more specifically, less than or equal to 
zero ( "Pcsitionlnvalid" ) . 
5 Note: The two integers in the list are suitable as the 

arguments of operaticn "substring". 

subst itute : 

op { repetitions: Integer; 

string: unprotected String!; 
) replacement: protected String!) 

Integer; 



Searches the first string (argument "string"), 
beginning at position one, for the longest possible 
substrings that match the responder, and modifies the 
5 string by replacing each match with a copy of the second 
string (argument "replacement") . 

The operation finds either all matches, if the 
integer (argument: "repetitions") is zero, or at most that 
many, otherwise. Successive matches are non-overlapping. 
If one match is of zero length, the search for the next 
begins at the following position. The operation returns 
the number of matches actually found. 

The replacement string can be tailored for each 
individual replacement. Wherever an ampersand (■'&") 
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appears in the replacement string without being 
immediately preceded by a reverse slash ("\">, a copy of 
the substring to be replaced is itself substituted for the 
ampersand, and the modified replacement string then is 
5 substituted for the substring. 

Adaptations 
isEaual 

Two patterns are equal according to their texts. 

Conversions 
10 String 

A string that is valid as the text of a pattern 
produces that pattern. 



4 . 57 Permit 
25 Object (Referenced) 

15 • Permit (Ordered) 



Class 

Permit : 

interface (Object, Ordered) = (...)/ 
Construction 
20 initialize : 

unprotected cp (age, charges, extent: Integer j Nil ) ; 



Makes the responded s attributes the like-named 
40 arguments (arguments "age", "charges", and "extent"). 

Makes every other native attribute of the responder either 
25 "true", if the attribute is a boolean, or a nil, 
otherwise . 



Public Instance Attributes 
age : 

Integer | Nil ; 
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Either the maximum permitted age, measured in 
seconds, of the responded s subject, if a maximum is 
imposed, or a nil, otherwise. 

authenticity : 
5 Integer j Nil ; 

Either the maximum permitted authenticity of the 
respor.der's subject, if a maximum is imposed, or a nil, 
otherwise . 

charges : 
0 IntegerjNil; 

Either the maximum permitted charges, measured in 
teleclicks, of the responded s subject, if a maximum is 
imposed, or a nil, otherwise. 

extent : 
5 Integer! Nil; 

Either the maximum permitted size measured in octets 
of the responder's subject, if a maximum is imposed, or a 
nil, otherwise. 

priority: 
0 Integer | Nil ; 

Either the maximum permitted priority of the 
responder's subject, if a maximum is imposed, or a nil, 
otherwise . 

canCharoe : 
5 Boolean; 
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Whether the responder's subject is permitted to 
request operation "charge". 

canCreate : 
Boolean ; 

5 Whether the responder's subject is permitted tc 

request operation "new" of a subclass of class "Process" 

canDeny : 
Boolean; 

Whether the responder's subject is permitted to set 
10 the "nativePermit" attribute of a peer process so as to 
decrease the peer process' capabilities. 

Whether, coincidental!/ , the responder's subject, i 
otherwise entitled tc do so, is permitted to so set a 
process' regionalPermit " or " local Permit " attribute. 

15 canGc : 

Boolean; 

Whether the responder's subject is permitted to 
request operation "go" . 

canGrant : 
0 Boolean; 



Whether the responder's subject is permitted to set 
the "nativePermit" attribute of a peer process so as to 
increase the peer process' capabilities. 

Whether, coinc identally , the responder's subject, if 
5 otherwise entitled to do so, is permitted to so set a 
process' "regionalPermit" or « localPermi t " attribute. 



canRestart : 
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Boolean; 

Whether the responder's subject is permitted to be 
restarted . 

canSend : 
5 Boolean; 

Whether the responder's subject is permitted to 
request operation "send" . 

Public Instance Operations 
intersect ion : 
0 op (permit: Permit) Permit; 

Returns the intersection of the argument (argument 
"permit") and the responder. 

Adaptations 
isAf ter 

One permit is after another iff they are not equal, 
no native attribute of the first is before that of the 
second, and at least one native attribute of the first is 
after that of the second. 

isSef ore 

One permit is before another iff they are not equal, 
no native attribute of the firsc is after that of the 
second, and at least one native attribute of the first is 
before that of the second. 

isEqual 

Two permits are equal according to their native 
attributes . 

4.58 Petition 



269 



EPO 634 719 A2 



Obj ect (Referenced) 
• Pec it ion 

Class 

Pet it ion : 

interface = (...); 

Construction 

initialize : 

unprotected op (agentName: Telename ! Nil ; 
agentclass : Citation j Nil ; 
maximumWait : Integer] Nil) ; 

Makes the responder's native attributes the 
like-named arguments (arguments "agentclass " , "agentName 1 
and "maximumWait " ! . 

Public Instance Attributes 
5 agentclass : 

Citation J Nil ; 

Either a citation to the class, a subclass of class 
"Agent", of which the petitionee of the meeting the 
responder defines is a member, if such a constraint is 
0 imposed, or a nil, otherwise. 

agentName : 
Telename [Nil / 

Either a telename of the petitionee of the meeting 
the responder defines, if such a constraint is imposed, o 
a nil, otherwise. 

maximumWait : 
Integer [Nil; 
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Either the maximum permitted difference in seconds 
between the time at which the meeting the responder 
defines shall be arranged and the time at which the 
meeting is requested, if such a constraint is imposed, or 
5 a nil, otherwise. The integer, if supplied, is 
non-negative . 

Adaptations 
isEaual 

Two petitions are equal according to their native 
0 attributes. 

4.59 Petitioned 
Petitioned 

Class 

Petitioned : 
5 abstract interface () = (...); 

System Instance Operations 
meeting : 

unprotected op (contact: Contact; 
petition: protected Petition) 
) throws MeetingDenied; 

Successfully performed before the subject of the 
contact {argument "contact") meets the responder using the 
petition (argument "petition"). The contact's subject 
attribute is a nil while the operation is being performed, 
and is made the "subject" iff the operation succeeds. 

An exception is thrown if the meeting is denied 
("MeetingDenied"). The method for this operation native 
to the class throws an exception. 

parting : 

unprotected op (contact: Contact); 
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Requested after the subject of the contact (argument 
"contact") has met with the responder. Before the 
operation is requested, the Engine makes che contact's 
"subject:" attribute a nil. The method native to class 
5 "Petitioned" has no effect. 

4 . 60 Place 

Object (Referenced) 

• Process (Named) 

• • Place (Unmoved) 

0 Class 

Place : 

abstract interface (Process, Unmoved) =(...); 

Construction 

init ialize 

5 Makes the responder' s "address" attribute a newly 

assigned celename, which is a peer of the current 
process' , and clears the responder' s "publ icClasses " 
attribute . 

Public Instance Attributes 
0 address : 

sealed readonly protected Teleaddress; 

The responder 's assigned teleaddress. 

publicClasses : 

sealed readonly Set [Cited] ; 

5 The set of classes, packages, or both that the 

responder hereby makes accessible to its occupants. The 
attribute is either an unprotected reference, if the 
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requester is the place, or a protected reference, 
otherwise . 

Public Instance Operations 
terminate : 
5 sealed unprotected op 

(occupant: protected Telename) Boolean 
throws FrocessNotCurrent , ProcessNotPeer , 
St ate Improper ; 

Terminates any occupant of the responder having the 
0 assigned telename (argument "occupant") and returns an 
indication of whecher there was such a process. The 
process is terminated by forcibly exhausting the process' 
native permit . 

An exception is thrown if the responder is not the 
5 current place ( "ProcessNotCurrent " ) , the current process 
is not the occupant's peer ( " PrccessNotPeer " ) , or the 
requester's state precludes operation "terminate" 
("Statelmproper" ) . 

System Instance Operations 
entering : 

unprotected op (contact: Contact; 
permit: protected Permit; 
ticket: protected Ticket j Nil ) 
throws OccupancyDenied; 

Successfully performed before the subject of the 
contact (argument "contact") occupies the responder. The 
contact's "subject" attribute is a nil when the operation 
is requested, but is made the subject iff the operation 
succeeds . 

The subject is either an agent arriving with the 
ticket (argument "ticket"), if one is supplied, or a 
process being created in the responder, if a nil is 
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supplied. The permit (argument "permit") is the subject's 
proposed initial local permit. 

After this operation succeeds, iff the responder is a 
contacted object, the Engine includes the contact in the 
responder' s "contacted" attribute. 

An exception is thrown if the contact's subject is 
denied occupancy ( "OccupancyDenied" ) . The method for this 
operation native to the class throws an exception. 
Note : If a ticket is supplied, the permit equals and, 

therefore, duplicates the ticket's 
"dest inat ionPermi t " attribute. 

exiting : 

unprotected op {contact: Contact; 
permit: protected Permit; 
ticket: protected Ticket|Nil); 

Requested once the subject of the contact (argument 
"contact") no longer occupies the responder. The 
contact's "subject" attribute is a nil when the operation 
is requested. The method for this operation native to the 
class has no effect. 

The subject is either an agent leaving the responder 
with the ticket (argument "ticket"), if one is supplied, 
or a process being destroyed within the responder, if a 
nil is supplied. The permit (argument "permit") is the 
subject's current local permit. 

After this operation is performed, iff the responder 
is a contacted object, the Engine excludes the contact 
from the responder' s "contacted" attribute. 

4.61 Primitive 
Object (Referenced) 

• Primitive (Executed & Unchanged) 
Class 
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Primitive : 

abstract interface {Object, Executed, Unchanged) 
(...); 

This class is sealed. 

5 Construction 

ini t ialize : 

unprotected op () 

throws FeatureUnavailable ; 

Throws an exception ("FeatureUnavailable"). 

.0 4.62 Primitive Exception 
Object (Referenced) 

• Exception (Unchanged) 

• • Programming Exception 

• • • Primitive Exception 

5 Class 

Prirni tiveExcept ion : 

abstract interface ( ProgrammingExcept ion) = (); 

Subclasses 

DivisionBvZero : 
0 interface (Primit iveExcept ion) = () 

A divisor is zero. 

4 . 63 Procedure 

Obj ect (Referenced) 

• Primitive (Executed & Unchanged) 
5 • • Procedure 

Class 

Procedure : 
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sealed interface (Primitive) = (...}; 

Adaptations 
isEgual 

Two procedures are equal iff they are equal in lengc 
5 and their like -posit ioned items are equal. 

Conversions 
List 

A list whose items are executed objects produces a 
procedure of the same length, each of whose items is a 
0 copy of that in the same position. 

OctetStrir.g 

An octet string that is a binary telescript produces 
a procedure whose items are the objects the binary 
telescript encodes . 

5 String 

A string that is 
procedure whose items 
telescript encodes . 

4 . 64 Process 
0 Object (Referenced) 
• Process (Named) 

Class 

Process : 

abstract interface (Object, Named, Uncopied) = (...); 

5 This class is sealed. 

Construction 

initialize : 

op ( nativePermit : copied Permit; 



a character telescript produces a 
are the objects the character 



276 



EP 0 634 719 A2 



privateClasses : Set [Cited] ]N T il) 
throws PermitViolated; 

Makes the responder's "name" attribute a newly 
assigned teiename, a peer of the current process' ; the 
5 responder's attribute the like-named argument (argument 
"nativePermit " ) ; the responder's "privateClasses " 
attribute either the like-named argument (argument 
"privateClasses"}, if the argument is net a nil, or the 
like-identified attribute of the current process, 
0 otherwise; and the responder's contacts attribute a 
cleared sec . 

An exception is thrown if the current process' 
effective permit forbids operation "new", that permit is 
otherwise inadequate, or operation "entering" fails 
5 { " PermitViolated" ) . 

Note: The method for this operation native to a 

subclass of class "Process" sees the creating 
process, not the created one, as the current 
process . 

0 Public Instance Attributes 
brand : 

sealed readonly protected Object 
throws ProcessNotPeer ; 

The responder's brand, 
5 An exception is thrown if the current process is not 

the responder's peer ("ProcessNotPeer"). 

local Permit : 
sealed copied Permit 

throws FeatureUnavailable, PermitViolated; 
The responder's local permit. 
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An exception is thrown if either the requester is 
neither the responder nor the place the responcier occupies 
( "FeatureUnavailable" ) or an attempt is made to set the 
attribute in a way which is inconsistent with the Process 
5 Model ( "PermitViolated" ) . 

nativePermit : 
sealed copied Permit 

throws FeatureUnavailable, PermitViolated; 

The responder 's native permit. 
0 An exception is thrown if either the requester is 

neither the responder nor a peer thereof 
( " FeatureUnavailable" ) or an attempt is made to set the 
attribute in a way which is inconsistent with the Process 
Model {"PermitViolated") . 

5 permit : 

sealed readonly copied Permit; 

The responder' s effective permit. 

regionaiPermit : 
sealed copied Permit 
0 throws FeatureUnavailable, PermitViolated; 

The responder' s regional permit. 

An exception is thrown if either the requester is 
neither the responder nor an engine place 
("FeatureUnavailable" ) or an attempt is made to set the 
5 attribute in a way inconsistent with the Process Model 
("PermitViolated") . 

privateClasses : 

sealed readonly Set [Cited] 

throws ProcessNotPeer ; 
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The sec of classes, packages, cr both the responder 
holds . 

An exception is thrown if the current process is not 
.he responder ' s peer ( " ProcessNct Peer " ) . 

5 Public Instance Operations 
charae : 

sealed op (charges: Integer) 

throws Permit Inadequate, Permit Viola ted ; 

Increases the responder' s actual charges by the 
0 integer amount (argument "charges"). 

An exception is thrown if the responder' s effective 
permit would be exhausted (" Permit Inadequate" ) or the 
current permit forbids operation "charge" 
{ "Permitviolated" ) . 

5 restrict : 

sealed op (procedure: Procedure; permit: protected 
Permit ) 

throws Exception, Permit Violated, ProcessNotCur rent ; 

Performs the procedure (argument " procedure" ) under 
the temporary permit (argument "permit") and the resulting 
effective permit of the current process, to which the 
procedure's charges accrue. 

An exception is thrown if the procedure dees so 
("Exception"), the procedure's performance violates the 
effective permit designated above { "Permitviolated" ) , or 
the requester is not the current process 
( " ProcessNotCurrent " ) . 

sponsor : 

sealed op (procedure: Procedure; permit: protected 
Permit) 

throws Exception, Permitviolated, ProceasNotCurrent ; 
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Performs the procedure (argument "procedure") under 
the temporary permit ("permit") and the resulting 
effective permit of the responder's owner, to which the 
procedure's charges accrue. The procedure gets access to 
5 the requester's frame and properties, not the responder's 
An exception is thrown if the procedure dees so 
("Exception"), the procedure's performance violates the 
effective permit designated above ( " PermitViolated" ) , or 
the requester is 
10 not the current process ( " ProcessNotCurrent " ) 

Private Instance Attributes 
age : 

sealed readonly Integer; 

The responder's actual age in seconds. 

5 charges : 

sealed readonly Integer; 

The responder's actual charges in teleclicks. 
priority : 

sealed Integer j Nil ; 

0 The responder's actual priority, i.e., the 

responder's chosen priority. 

Private Insf ance Operations 
wait : 

unprotected op (seconds: Integer); 

5 3locks the responder until the requested number of 

seconds (argument "seconds' 1 ) have elapsed. If the integer 
is negative, the operation has no effect. 
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System Instance Operations 
live : 

abstract unprotected op (cause: Exception j Nil ) 
throws Except ion ; 

Requested with a nil (argument "cause") to start the 
responder after its creation. If the "canRestart" 
attribute of the permit the responder holds is "true", the 
operation is requested with an exception (argument 
"cause") to restart the responder if the responder fails 
due to that exception. 

An exception is thrown if the responder fails to 
catch the exception ("Exception"). 

restricted : 

op (permit: Identifier; isRelocated: Boolean) 
PermitReduced j Nil ; 

Requested if the responder 's attribute 
"nativePermit " , " regionalPermit " , or " lccalPermi t " , once 
set, is set again so as to reduce the responder' s 
capabilities. The identifier {argument "permit") is that 
of whichever of these three attributes was set. The 
Engine throws the operation's result in the responder' s 
thread if the result is net a nil. The method native to 
this class simply returns a nil. 

The boolean (argument "isRelocated") indicates 
whether the event leading the Engine to request the 
operation also led the Engine to transport the responder 
to a place, e.g., a purgatory, other than either the one 
the responder occupied or, if zhe operation is requested 
during the performance of operation "go" or "send", the 
responder' s destination. In the latter case, operation 
"go" or "send" throws the present operation's result if 
not a nil. 
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Note: The responder's ability to perform this 

operation, when the responder's newly sec permit 
is severely restrictive, is limited by the rules 
of process termination. 

5 Adaptations 
copy 

A member of "Copy Unavailable" is thrown. 

4.65 Process Exception 
Object (Referenced) 
10 • Exception (Unchanged) 

• • Programming Exception 

• • • Process Exception 



Class 

25 ProcessException : 

15 abstract interface { ProgrammingExcept ion) = () 



Subclasses 

Permit Inadequate : 

interface (ProcessException) = (); 

One process tries no charge another so as to exhaust 
20 the latter' s effective permit. 

Condit ionUnava liable : 

interface (ProcessException) = (); 

A process manipulates the condition of a resource 
without exclusive use of the resource. 
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Condi t ionUndef ined : 

interface (ProcessException) = (); 

An identifier purporting to denote a resource's 
condition dees not. 

Permit Exhausted : 

interface (ProcessException) = (); 

A process exhausts the permit that the process holds 
Perm it Viol a ted : 

interface (ProcessException) = (); 

A process violates the permit that the process holds 
ProcessNot Current : 

interface (ProcessException) = (); 

A process requests a feature of other than the 
current member of a class. 

ProcessNot Peer : 

interface (ProcessException) = (); 

An object manipulates a process that is not the 
object's peer. 

Resource Unavailable : 

interface (ProcessException) = (); 

A resource's use cannot be obtained in the number of 
seconds requested. 
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Stacelmproper : 

interface ( ProcessExcept ion) = 0 

A process requests a feature whil 
precludes the request . 

5 4.66 Programming Exception 
Object (Referenced) 

• Exception (Unchanged) 

• • Programming Exception 

Class 

0 ProgrammingExcepticn : 

abstract interface (Exception) = 

4.67 Qualified Identifier 
Object (Referenced) 

• Primitive (Executed & Unchanged) 
5 • • Identifier (Ordered) 

• • • Qualified Identifier 

Class 

Qua 1 if iedldent if ier : 

sealed interface (Identifier) = () 

> 4.58 Random Stream 
Obj ect (Referenced) 

• Stream 

• • Random Stream 
Class 

Randoms t ream : 

interface (Stream [Integer]) = (.. 
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Construction 

initialize : 

unprotected op (seed: Integer) 
throws Seedlnvalid; 

5 Makes the responder's seed the integer (argument 

"seed"), makes the responder's "current" attribute a nil, 
and leaves the responder's "next" attribute undefined. 

An exception is thrown if the proposed seed is 
invalid as such ("Seedlnvalid"). 

10 Adaptations 
current 

This attribute is an integer. 
next 

This attribute is an integer, and not a nil. 

15 4.69 Real 

Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Number (Ordered) 

• • • Real 

2 0 Class 

Real : 

sealed interface (Number) = () ; 

Adaptations 
abs 

25 The result is a real. 

add 

The result is a real. 
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divide 

The result is a real. 
multiply 

The result is a real. 

5 negate 

The result is a real . 

subtract 

The result is a real. 

Conversions 
10 Bit 

A bit produces the result of first converting the bit 
to an integer, and then converting the integer to a real. 

BicStrina 

A bit string produces the result of first converting 
15 the bit string to an integer, and then converting the 
integer to a real . 

Boolean 

A boolean produces the result of first converting the 
boolean to an integer, and then converting the integer to 
10 a real. 

Character 

A character produces the result of first converting 
the character to an integer, and then converting the 
integer to a real . 

5 Integer 

An integer produces the real that is equal to the 
integer arithmetically. 
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Octet 

An octet produces the result cE first converting the 
octet to an integer, and then converting the integer to a 
real . 

CctetString 

An octet string produces the result cf first 
converting the octet string to an integer, and then 
converting the integer co a real. 



String 

10 A string that obeys the syntactic rules for the Real 

20 token in Character Telescript produces the corresponding 

real . 



4 . 70 Referenced 
Referenced 

15 Class 

Referenced : 

abstract interface () = {...); 

This class is sealed. 

Public Instance Attributes 
2 0 isPrctected : 

sealed readonly Boolean; 

Whether the reference to the responder is protected. 

Public Instance Operations 
discard : 
25 sealed op ( ] ; 

Destroys the responder iff no references to the 
responder remain . 
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isSame : 

sealed op {reference: protected Referenced) Boolean; 

Returns an indication of whether the referenced 
object (argument "reference") is the responder. 

protect : 

sealed op 0 protected Referenced; 

Returns a protected reference to the responder. 



sealed unprotected op (5 ; 

10 Pushes onto the stack two references to the 

responder, both protected iff the reference used to 
request the operation is itself protected. 

4.71 Resource 
Object (Referenced) 
15 • Resource 

Class 

Resource : 

interface = (...); 



Construction 
40 2 0 initialize : 

unprotected op (condition: Identifier! |Nii; 

conditions: copied Set [Identifier !] | Nil) 
throws ConditionUndef ined; 



Makes the responder' s native attributes the 
!5 like-named arguments (arguments "condition " and 

"conditions"). If either argument is a nil, both must be 
nils, and in that eventuality, the "conditions" attribute 
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comprises one identifier which equals the "condition" 
attribute. The identifier in question is undefined. 

An exception is thrown if the individual condition 
i.e. the "condition" attribute, is not in the set, i.e. 
5 not in the "conditions" attribute ( "CcnditionUndef ined" 

Public Instance Attributes 
condi z ion : 
Identifier ! 

throws Condit icnunavailable ; 

0 The identifier for the responder's condition. 

An exception is thrown if the current process 
attempts to set the attribute and lacks exclusive use o 
the responder ( "CcnditionUnavailable " ) . 

conditions .- 

5 readonly protected Set [Identifier!]; 

The identifiers for the responder's possible 
conditions . 

Public Instance Operations 
use : 

0 sealed unprotected op (procedure: Procedure; 

exclusive : Boolean) Nil ; 
maximumWait : Integer | Nil 

conditions: copied Set [Identifier!] [Nil) 

3oolean 

5 throws Condi tionUnde fined, Exception, 

RescurceUnavailable ; 

Obtains use of the responder, performs the procedur 
(argument " procedure ") , and then relinquishes the 
responder, even if the procedure fails. The procedure 
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gees access to the requester's frame and properties, net 
"he responder's. 

The use is exclusive iff the boolean (argument 
"exclusive") is both present and "true". Iff a set of 

5 identifiers (argument "conditions"}, not a nil, is 

supplied, the use is granted only when the responder is 
one of the conditions the identifiers denote. 

If an integer {argument "maximumWait " ) is supplied, 
the operation waits for use of the responder no more tha 

0 that many seconds. If a nil is supplied instead, the 
operation waits as long as required, possibly forever. 
The operation's result indicates whether, in the former 
case, the responder remained unavailable after the 
indicated number cf seconds. 

An exception is thrown if the set of conditions is 
cleared or does net equal a subset of the responder's 
"conditions" attribute ( "CcnditionUndef ir.ed" ) , the 
procedure throws an exception ("Exception"), or the 
responder's use cannot be obtained in the number cf 
seconds requested ( "ResourceUnavailabie " ) . 

4 . 72 Selector 
Object (Referenced) 

• Primitive (Executed & Unchanged) 

• • Selector 

Class 

Selector : 

sealed interface (Primitive) = {); 

Adaptations 
isSaual 

Two selectors are equal iff their values are the 

same . 
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4 . 73 Set 

Obj ect (Referenced) 

• Collection 

• • Set (Verified) 

5 Class 

Set : 

interface [itemClass: Class] 

(Collection [itemClass], Verified) = (...); 

Parameterized by the class (argument "itemClass") c 
0 which each item o: each member of the subject class is 
itself a member. 

Construction 

initialize : 

unprotected op (items: itemClass . ..) 

5 throws ItemDuplicated, I temlnval id; 

Makes the responder's items the objects (argument 
"items" ) . 

An exception is thrown if two proposed items are 
equal ( " ItemDuplicated" ) or a proposed item is invalid a 
0 such ( " Itemlnvalid" ) . 

Public Instance Operations 
di f f erence : 

unprotected op (set: protected Set [itemClass]); 

Excludes from the responder and discards every item 
5 that equals an item of the set (argument "set") . 
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intersection : 

unprotected op (set: protected Set [itemClass]); 

Excludes from the responder and discards every itei 
that does net equal an irem of the set (argument "set") 

5 union : 

unprotected op (set: protected Set [itemClass]); 

Includes in the responder a reference to each item 
the set (argument "set") that does not equal an existinc 
item of the responder. 

-0 Adaptations 
include 

An object is included in a set as a new item by fir 
excluding and discarding any existing item equal to the 
cbj ect . 

5 verify 

A sen is consistent iff no two of the set's items a 

equal . 

4.74 Stack 
Object (Referenced) 
0 • Collection 

• • List (Ordered) 

• • • Stack 
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Class 

Stack : 

interface [itemClass: Class] (List [itemClass]) = 
{...); 

5 Parameterized by the class (argument "itemClass") c 

which each item of each member of the subject class is 
itself a member. 

Public Instance Operations 
pop : 

0 unprotected op () itemClass 

throws StackDepleted ; 

Removes from the responder and returns its top item. 
An exception is thrown if the responder is cleared 
( "StackDepleted'* ) . 

5 push : 

unprotected op (item: itemClass); 

Adds the object (argument "item") to the responder a 
a new item at its top. 

pushl terns : 

unprotected op (items: protected List [itemClass] ) ; 

Pushes onto the responder references to the items of 

the list (argument "items"). A reference to the item at 

position one of the list is placed on top of the 
responder . 
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roll : 

unprotected cp (shifts, items: Integer) 
throws Argument Invalid, StackDepleted; 

Shifts the topmost items of the responder. 
5 The number of items, "I", participating in the shift 

is given by one integer (argument "items") which shall be 
non-negative. The number of positions, "P», that each 
participating item is tc be shifted is given by another 
integer (argument "shifts") which may be either positive 
10 or negative, "P" being its absolute value. The 
participating items are shifted toward either the 
responder' s top, if this second integer is positive, or 
the responder' s bcttcm, otherwise. 

To shift the participating items one position toward 
15 the responder' s top is to change the position of the 

topmost item to "I" and to decrease by one the position of 
each of the ether participating items. 

To shift the participating items one position toward 
the responder' s bottom is to make topmost the item whose 
20 position is "I" and to increase by one the position of 
each of the other participating items. 

An exception is thrown if the integer giving "I" is 
negative ( "Argument Inval id" ) or the responder' s length is 
less than "I" ("StackDepleted"}. 

5 swap : 

unprotected op {} 
throws StackDepleted; 

Transposes the items at positions one and two of the ' 
responder . 

0 An exception is thrown if the responder' s length is 

less than two ("StackDepleted"}. 
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4 . 75 Stream 

Cbj ect (Referenced) 

• Stream 

Class 

Stream : 

abstract interface [itemClass: Class] = (...); 

Parameterized by the class (argument "itemClass") of 
which each item of each member of the subject class is 
itself a member. 

Public Instance Attributes 
current : 

abstract readonly itemClass ] Nil ; 

Either the item the responder produced last, if 
attribute "next" of the responder has been queried but ha 
not returned a nil having produced all of the responder' s 
items, or a nil, otherwise. 

is Done : 

abstract Boolean; 

Whether the responder has produced all of its items. 
next : 

abstract readonly itemClass ! Nil 
throws Ref erenceFrctected ; 

Either the next item cf the responder, if the 
responder has not produced all of its items already, or a 
nil, otherwise. The responder produces another item each 
time this operation is requested. 

An exception is thrown if the responder is protected 
{ "Ref erenceProtected" ) . 
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4 . 76 String 

Object (Referenced) 

• Collection 

• • List (Ordered) 

5 • • • Constrained List (Constrained) 

• • • • String {Cased i Executed) 

Class 

String : 

sealed interface 
0 (ConstrainedList [Character] , Cased, Executed) = 

(...); 

Construction 

initialize : 

unprotected op (segments: Object ... 
5 /* Character! protected String! */) ; 

Makes the responder a concatenation of the segments 
(argument "segments") whose positions in the responder 
increase from left to right. 

Public Instance Operations 
0 substring : 

op (initialPosition, beyondFinal Posit ion : Integer} 
copied String 
throws Positionlnvalid; 

Returns a copy of the substring of the responder that 
5 comprises the characters at the positions in the range 
["initialPosition" , "beyondFinalPosit ion" ) . 

An exception is thrown if an asserted position is 
invalid as such ("Positionlnvalid") . 
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Adaptations 

constraint 

The attribute is sealed. The " constraint " 
attribute' s "ofClass" , "ciassld" , " is Instance " , 
" isOpt ionai " , and "passage" attributes are class 
"Character", the identifier of class "Character", "true", 
"false", and "byCopy" , respectively. 

isAf ter 

One string is after another as if enough characters 
were first appended to the shorter string to make the 
shorter string equal in length to the longer string, each 
appended character being that whose Unicode code is the 
integer zero. 

isBef ore 

Cne string is before another as if enough characters - 
were first appended to the shorter string to make the 
shorter string equal in length to the longer string, each 
appended character being that whose Unicode code is the 
integer zero. 

Conversions 
Bit 

A bit that can be converted to a character that can 
be converted to a string produces that string. 

CalendarTime 

A calendar time produces a string describing the time 
represented by the calendar time. 

Character 

A character produces a string whose only item equals 
the character. 
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Ident i f ier 

An identifier produces a string chat equals the 
identifier's text. * 

Integer 

5 An integer produces a string that obeys the syntactic 

rules for the "Integer" token in a character telescript . 

Pattern 

A pattern produces a string that equals the pattern's 

text . 
.0 Real 

A real produces a string that obeys the syntactic 
rules for the "Real" token in a character telescript. 

Telenumber 

A telenumber produces the concatenation of a plus 
5 sign {"+"), the telenumber ' s country attribute, a space 
(" "), and the celenumber's "telephone" attribute. 

Time 

A time produces the result of first converting the 
time to a calendar time, and then converting the calendar 
0 time to a string. 

4 . 77 Teleaddress 
Object (Referenced) 
• Teleaddress 

Class 
5 Teleaddress : 

interface = (...); 
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Construction 

initialize : 

unprotected op (provider: OctetString ! | Nil ; 
location: String! J Nil ) ; 

S Clears the responded s " rout ingAdvice " attribute and 

makes its other native attributes the like-named arguments 
{arguments "lccation" and "provider M ). If the latter 
argument is a nil, however, the "provider" attribute is 
mace that of the current place's assigned teieaddress. 

0 Public Instance Attributes 
location : 
String! |Nii; 

Either the string denoti 
denoted by the responder, if 
5 such a constraint is imposed, 

provider : 
OctetString! ; 

The octet string denoting, as does a telename's 
"authority" attribute, the provider of the region 
containing the places the responder denotes. 

rout ingAdvice : 
List [OctetString!] ; 

Octet strings denoting, as does the "provider" 
attribute, and in order of decreasing preference, the 
providers of transit regions. 



r.g the location of the places 
the latter is assigned or 
or a nil, otherwise. 
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Adaptations 
is Equal 

Two teleaddresses are equal according to their native 
attributes . 

5 4.73 Tele name 

Obj ect (Referenced) 
• Telename 

Class 

Telename : 
10 interface = (...),- 

Construction 

initialize : 

unprotected op (authority, identity: 
OctetString! [Nil) ; 

15 Makes the responded s native attributes the 

like-named arguments (arguments "authority" and 
"identity"). If the former argument is a nil, however, 
the "authority" attribute is made that of the current 
process' assigned telename. 

20 Public Instance Attribute; 
authority: 
OctetString! ; 

The octet string denoting the authority of the named 
objects the responder denotes. 

25 identity : 

OctetString! jNil; 

Either the octet string denoting the identity of the 
named object denoted by the responder, if the latter is 
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assigned or such a constraint: is imposed, or a nil, 
otherwise . 

Adaptat ions 
isEaual 

Two telenames are equal according to their native 
attributes . 

4.79 Tele number 
Object (Referenced) 
• Telenumber 

Class 

Tele nuT.be r : 
interface = (...); 

Const ruct ion 

init ialize : 

unprotected op ( count ryAndTelephone : String!; 
extension: String ! j Nil ) ; 

Makes the responder's "extension" attribute the 
like-named argument (argument "extension 1 ') and the 
responder's other native attributes those of a telenumbe 
that can be converted to the " count ryAndTelephone " 
argument . 

Public Instance Attributes 
country : 
String ! ,- 

The code that CCITT assigns to the country or other 
geographical area in which the instrument the responder 
denotes is located [CCITT] . Each character of the strin 
is a numeral ( " 0 " - " 9 " ) . 
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extens ion : 
String! [Nil; 

Either the telephone extension that unambiguously 
identifies the instrument the responcier denotes, if the 
5 responder's "country" and "telephone" attributes do not do 
that themselves, or a nil, otherwise. Each character of 
the string is a numeral { " 0 ;t - " 9 " } , a hyphen ("-"), or a 
space ( " " ] . 

telephone : 
10 String!; 

The number assigned to the instrument the responder 
denotes by the country or other geographical area the 
"country" attribute denotes. Each character cf the string 
is a numeral ( " 0 " - " 9 " } , a hyphen ("-"), or a space ( " "). 

1 5 Adaptations 
isEqual 

Two telenumbers are equal according to their native 
attributes, which are equal as if all hyphens ("-") and 
spaces (" ") were first dropped from them. 

2 0 Conversions 
String 

A string that can be produced by converting some 
telenumber produces that teienumber, whose "extension" 
attribute is a nil. 

25 4.30 Ticket 

Object (Referenced) 

• Ticket Stub 

• • Ticket 
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10 



Class 

Ticket : 

interface (TicketStub) = (...); 

Construct: ion 
5 initialize : 

unprotected op (destinat ionName : Telename [ Nil ; 
destinat ionAddress : Teleaddress j Nil ; 
15 destinat ionClass : Citat icn | Nil ; 

maximumWaic ; Integer | Nil; 
10 way: Way | Nil; 

travelNotes: Object | Nil) ; 
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Makes the responder's "desiredWai t " and 
"destinatior.Permit" attributes nils, the responder's other 
attributes the like-named arguments (arguments 
15 "descinationAddress" , "dest inacionClass M , 

"destinationName" , "maximumWait " , "travelNotes" , and 
"way", respectively) . 

Public Instance Attributes 
desiredWait : 
20 Integer j Nil ; 

Zither the maximum desired difference in 
seconds- -non-negative- -between the time the trip the 
responder defines should be completed and the time the 
rrip is requested, if such a constraint is imposed, or a 
25 nil, otherwise. 

destinat ionAddress : 
Teleaddress j Nil ; 

Either a teleaddress of the destination of the trip 
the responder defines, if such a constraint is imposed, or 
30 a nil, otherwise. 
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dest inationClass : 
Citation j Nil; 

Either a citation to the subclass of class "Place" o 
which the destinaticn of the trip the responder defines i 
5 a member, if such a constraint is imposed, or a nil, 
otherwise . 

destinationName : 
Telename j Nil ; 

Either a telename of the destination of the trip the 
C responder defines, if such a constraint is imposed, or a 
nil, otherwise. 

destinat ionPermit : 
Permit j Mil ; 

Either the local permit an agent using the responder 
5 shall have at the agent's destination, if that permit 
differs from the agent's current temporary permit or, if 
the agent has none, the agent's native permit; or a nil, 
otherwise . 

maximumWait : 
C IntegerjNil; 

Either the maximum permitted difference in seconds 
between the time at which the trip the responder defines 
shall be completed and the time at which the trip is 
requested, if such a constraint is imposed, or a nil, 
5 otherwise. The integer, if supplied, shall be 
non-negative . 
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Adaptations 
isEgual 

Two tickets are equal according to their attributes 
native to rickets and ticket stubs. 



5 4.81 Ticket Stub 
Object (Referenced) 
• Ticket Stub 



Class 

TicketStub : 
10 interface = (...); 

Construction 

ini t iali ze : 

unprotected op (way: Way | Nil; traveiNotes: 
Object [Nil) ; 



Makes the responder's native attributes the 
like-named arguments (arguments "traveiNotes" and "way"). 

Public Instance Attributes 
traveiNotes : 
Object] Nil; 

An object for the exclusive use of the agent holding 
che responder. 

way : 

Way | Nil; 



In a ticket, either the way to be taken to the trip's 
25 destination, if such a constraint is imposed, or a nil. 
In a ticket stub, a way back to the trip's origin. 
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• 



Adaptations 
5 isEqual 

Two ticket stubs are equal according to their native 
attributes . 

10 5 4.82 Time 

Object (Referenced) 

• Time (Ordered & Unchanged} 
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Class 

Time : 

10 interface (Object, Ordered, Unchanged) = (...}; 

Construction 

initialize 

Makes the responder the current time, namely, that at 
the current place. 

15 Public Instance Operations 
adjust : 

op (seconds: Integer) Time; 

Returns a time that is the requested number of 
seconds (argument "seconds") after the responder and that 
20 identifies the same permanent and seasonal offsets. 

the integer is negative, the time returned 
precedes the responder. 

interval : 

op (subtrahend: Time) Integer; 

25 Returns the arithmetic difference in seconds between 

the responder, which is the minuend, and the time 
(argument "subtrahend"), which is the subtrahend. 
Note: The result measures the distance between two 

absolute points in time. 
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Adaotat ions 
isAf ter 

One time is after another iff the absolute point in 
rime that the first identifies follows the absolute point 
5 in time that the second identifies. 

isBef ore 

One time is before another iff the absolute point in 
time that the first identifies precedes the absolute point 
in time that the second identifies. 

0 isEgual 

Two times are equal iff neither is before the other. 

Conversions 

CalendarTime 

A calendar time produces a time denoting the same 
5 point in time and the same permanent and seasonal offsets. 

4.33 Trip Exception 
Object (Referenced) 

• Exception (Unchanged) 

• • "Trip Exception" 

0 Class 

TrinExceot ion : 

abstract interface (Exception) = (...),- 

Construction 

initialize : 

5 unprotected op {ticketStub: TicketStub); 

Makes the responder's native attribute the like-named 
argument (argument "ticketStub") 

Subclasses 
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Destination-Unavailable : 
interface (TripExcept ion) = () ; 

A trip's destination is unreachable because the 
Network is partitioned. Thus the destination may be 
5 reachable in the future. 

DestinationUnknown : 

interface (TripExcept ion) = (} ; 

A trip's destination cannot be identified and thus is 
unreachable . 

0 OccupancvDenied : 

interface (TripException) = (); 

A trip's destination denies the agent occupancy and 
therefore arrival . 

TicketExpired : 
5 interface (TripException) = (); 

A trip's destination cannot be reached in the number 
of seconds requested by the "maximumWai t " attribute of the 
ticket for the trip. 

WavUnavailable : 
5 interface (TripException) = {); 

A trip's origin lacks the way required for the trip. 

Public Instance At t rihnt- pc; 
t icketStub : 
sealed TicketStub; 

The ticket stub resulting from the unsuccessful trip. 
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is Equal 

Two trip exceptions are equal according to their 
native attributes. 

5 4.34 Unchanged 
Unchanged 

Class 

Unchanged ; 

abstract interface ()=<); 

10 Adaptat ions 
copy 

A copy of an unchanged object is the original. 

25 4.35 Unexpected Exception 

Obj ect (Referenced) 
15 • Exception (Unchanged) 

• Programming Exception 

• • Kernel Exception 

• • • Execution Exception 

• • • • "Unexpected Exception" 

2C Class 

UnexpectedExcept ion : 

interface (Execut icnExcept ion) = (...); 

Cons truct ion 

initialize : 

25 unprotected op (exception: Exception); 

Makes the responder's native attribute the like -named 
argument (argument "exception"). 
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Public Instance Attr ibutes 
exception : 
readonly Exception; 

The exception, which a feature did not declare but 
5 nevertheless threw, that is the cause of the responder. 

4.86 Unmoved 
Unnoved 

Class 

Unmoved : 

l0 abstract interface 0 = () ; 

4 . 87 Verified 
Verified 

Class 

Verified : 

5 abstract interface () = (...); 

Public Instance Operations 
veri f y : 

abstract op () Boolean; 

Returns an indication of whether the responder is 
0 consistent. 

4 . 88 Way 

Object (Referenced) 
• Way 

Class 
5 Way : 

interface = (...),- 
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Construction 

initialize : 
unprotected op { 

name : Telename [ Nil ; 
5 means: Means 'Nil; 

authenticator : Authenticator ] Nil ) ; 

Makes the responder's native attributes che 
like-named arguments (arguments "authenticator", "means", 
and "name" ) . 

L0 Public Instance Attributes 
authent icator : 
Authent icator j Nil ; 

Either the authenticator to be used to enter the 
region through which the way passes, if such a constraint 
.5 is imposed, or a nil, otherwise. 

means : 
Means] Nil; 

Either the means by which the region through which 
the way passes is to be accessed, if such a constraint is 
0 imposed, or a nil, otherwise. 

name : 

Telename [Nil; 

Either the telename of the region through which the 
way passes, if such a constraint is imposed, or a nil, 
5 otherwise. 

Adaptations 
is Equal 
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Two ways are equal according to their native 
attributes . 

5 TELESCRIPT SYNTAX 

A " teiescript " is an encoding of a procedure. The 
5 abstract syntax of telescripts in general, and the 
concrete syntax of character and binary telescripts in 
particular, are defined in this section of this appendix. 
Note: Character telescripts are used by people, binary 

telescripts by machines, e.g., when transporting 
0 objects between them. A binary teiescript is 

almost always considerably fewer octets in 
length than the functionally equivalent 
character telescrict. 



5 . 1 Teiescript 

A teiescript is a series of tokens comprising, first, 
a preface and, second, the procedure that the teiescript 
encodes. The preface identifies the major and minor 
versions of the Instruction Set to which the teiescript 
conforms . 

A teiescript obeys the syntactic, and accompanying 
semantic, rules below. Given in BNF, the rules surround 
optional tokens by brackets ( " [ " and " ] " } : 



Teiescript 
Body 

5 ExecutedObject 
Character j Identifier 

Modifier | 

0 Eit 
Boolean 
Modifier 



= Preface Procedure 

= [ExecutedObject Body] 



= Bit ! BitString j Boolean J 

i 

i 



Integer ! 
Octet ! OctetString 
Nil 



Mark ! 



Procedure j Qldentifier 
Real | Selector j String 
3itZero j BitOne 
BooleanFalse ] BooleanTrue 
Modi fie rDemarcate j 
Modif ierGetClass j 
Modi fierGet Property ] 
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Modi fierGet Variable j 

i 
i 

Modif ierSetAttribute j 
Modif ierSet Property ] 
Modif ierSetVariable ] 
Modi fierUseS tack 
Selector : : = SelectorBreak ! 

SelectorClient ; 
Selec t orCont inue | 
Selec torEscal ate | 
SelectorPlace ] 

SelectcrSelf ] 
Selector Succeed 



5 A telescript can include comments, the provision for 

which is considered among the syntactic rules. A 
"comment" is a string that does not affect the procedure 
the telescript encodes. One or more comments can appear 
before the script's first token, after its last, and 
0 between any two adjacent tokens. 

Note : A comment usually describes an aspect of a 

telescript to a human being. 
Note: The major and minor versions of the Instruction 

Set as defined in this appendix are identified 
5 by zero ("0") and eight ("8"), respectively. 

5 . 2 Character Telescript 

A "character telescript" is a procedure encoded as a 
string. The abstract syntactic rules for telescripts in 
general are made concrete for character telescripts in 
0 particular in this section. 

Each token in a character telescript is one or more 
characters. The character telescript is obtained by 
concatenating the tokens, and thus the characters, and by 
inserting break characters between tokens. 
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A break: character is a space {" " ) , a horizontal tab, 
or a line feed. One or more such characters can appear 
before the first token, after the last, or between any two 
adjacent tokens. In the last case, at least one must 
5 appear if the two adjacent tokens comprise only numerals 
("0" -"9 M ) and letters, except when both tokens are either 
"3inDigit" or "hexDigit Pa ir " . 

Terminals beginning winh number sign <"#") and the 
keyword "telescript" are case - insensitive . While 
,0 upper-case characters appear in this appendix, lower-case 
characters, or a mix of the two, can be used in 
programming . 

5.2.1 Preface and Comment 

Preface 

5 A preface obeys these rules: 

Preface ::= telescript Version 
Version : : = numerals : numerals 



The first "numerals" identifies the major version of 
the Instruction Set to which a character telescript 
0 conforms, the second "numerals" identifies the minor 
version . 



Comment 

A comment obeys this rule: 

Comment ::= /* comment 1 */ | // comment 2 
5 Note: The syntax rules for comments are those of the 

C+- programming language. 

5-2.2 Executed Objects 

Bit 

A bit obeys these rules, which individually encode 
0 the bit' s values : 

BitZero : : = tfb * 0 ' 
BitOne : : #b ' l ' 



314 



EP 0 634 719 A2 



BitStrinq 

A bit string obeys these rules: 

BitString ::= #b " BinDigits " 
BinDigits ::= [BinDigit BinDigits] 

5 The 1 th "BinDigit: M represents the bic at position " 

of the bit string. 

Boolean 

A boolean obeys zhese rules, which individually 
encode the boolean' s values: 
0 BocieanFalse ::= ttfalse 

BocleanTrue ::= #true 

Character 

A character obeys this rule: 

Character ::= # c ' characters ' 

5 "characters" shall stand for one character. Each 

character stands for itself, with exceptions as defined 
for class "String". 

Identifier 

An identifier obeys this rule: 
0 Identifier ::= identifier ■ ] 

"identifier" is the identifier's text. The right 
square bracket ["]"] denotes operation "new". 

Integer 

An integer obeys this rule: 
5 Integer :: = [,] numerals 

Mark 

A mark obeys this rule : 

Mark : : = tfmark j [ 



315 



EP 0 634 719 A2 



55 



Note : 



Left square bracket [»["] is provided for 
possible use, by convention, with right square 
bracket ("l"] (see token "Identifier" above). 
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Modifier 

5 A modifier obeys these rules, which individually 

encode the modifier's values. 
Modif ierDemarcate 
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Modif ierGetClass 
Modif ierGet Property 
Modif ierGet Variable 
Modif ierMent ion 
Modif ierSe t Attribute 
Modif ierSet Property 
Modif ierSet Variable 
Modif ierUseS tack 



Nil 

A nil obeys this rule: 
Nil #nil 



% 
$ 



= =$ 



Octet 

An octet obeys this rule: 

Octet : : = #o ' hexDigitPair 



40 



45 



50 



25 



The MSB of "hexDigitPair" represents Bit 7 of the 
octet, the LSB represents Bit 0. 

OctetStrinq 

An octet string obeys these rules: 

OctetString ::= #o » KexDigitPairs " 
HexDigitPairs :: = [hexDigitPair HexDigit Pairs] 

The first "hexDigitPair" represents the octet at 
position one of the octet string, the second that at 
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position two, etc. The MSB of each "hexDigitPair" 
represents Bit 7 of that octet, the LSB represents Bit 0 



10 



Procedure 

A procedure obeys this rule: 
Procedure : : = { Body } 



15 



Oualif iedldent if ier 

A qualified identifier obeys this rule: 
Qldentifier identifier :: identifier 



20 



The first "identifier" represents the text; the 
10 second represents the qualifier. 
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Real 

A real obeys these rules : 

Real : : = Number [Exponent] 
Number Integer . numerals ] 

Integer . | 
numerals 
Exponent E Integer 
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The real's integral part is either the "Integer" in 
"Number", if present, or zero, otherwise. The real's 
20 fractional part is either "numerals", if present, or zero, 
otherwise. The "Integer" in "Exponent", if present, is a 
power of ten. 

Selector 

A selector obeys these rules, which individually 
25 encode the selector's values: 



30 



SelectorBreak 
SelectorClient 
SelectorContinue 
SelectorEscalate 
SelectorPlace 



#break 
^client 
fccont inue 
^escalate j 
She re 
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Select or Process 
SeiectorSel f 
SelectorSucceed 



= ^process 
= #self j * 
- ^succeed 



10 



S t r i no 

A string obeys this rule: 

String ::= [#c] " characters " 
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"characters" stands fcr zero or more characters. 
Each character stands for itself, except that a reverse 
slash f"\") and four hexadecimal digits {"0"-" 9" , ,, A"-"F" ! 
L0 stand fcr the character whose Unicode code is the unsigned 
integer the digits represent, a character pair in Table 
A. 6 for the indicated character. 



TABLE A . 6 
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Character Seouence 


Sinale Character 






\b 


Backspace 


\f 


Form feed 


\n 


Line feed (newline) 


\r 


Carriage return 


\t 


Horizontal tab 


\v 


Vertical tab 


V 


Quotation mark ( " " " ) 


\\ 


Reverse slash ("\") 
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5.2.3 Other Non-terminals 

characters 

IS Zero or more characters, each a printing character or 

a space {« "}. a quotation mark ( " ) shall be preceded by 
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a reverse slash ("\"). A reverse slash either shall be a 
part of a character sequence in the table found under 
token "String" above, or shall precede four hexadecimal 
digits . 

5 comment 1 

Zero or more characters, not including an asterisk 
immediately followed by a slash ("*/"). 

Note : " comment 1" can encompass M /*" or "//" without 

special meaning, and thus can encompass a 
0 "comment! " . 

comment 2 

Zero or more characters, not including a line feed. 
Note: "comment 2" can encompass "/*" , " */", or "//" 

without special meaning, and thus can encompass 
5 a " comment 1 " . "comment 2" cannot be followed on 

the same line by other tokens, since it would be 
considered to encompass them. 

hexDigitPair 

A pair of hexadecimal digits ("0"- n 9", " A" - " ?" ) 
ident i f ier 

Characters constrained as is the text of an 
identifier . 

numerals 

One or more numerals ("0"-"9"). 

5 . 3 3inarv Telescript 

A "binary telescript" is a procedure encoded as an 
octet string. The abstract syntactic rules for 
telescripts in general are made concrete for binary 
telescripts in particular in this section. 
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Each token in a binary teiescript is one or more 
octets . The binary teiescript is obtained by 
concatenating the tokens and thus the octets. 

5 ■ 3 ■ 1 Preface and Comment 

Preface 

A preface obeys these rules: 
Preface ::= Version 

Version ::= unsignedNumber unsignedNumber 

The first and second "unsignedNumber" identify the 
major and minor versions, respectively, of the Instruction 
Set to which a character teiescript conforms. 

Comment 

A comment obeys this rule: 

Comment ::= tag unsignedNumber characters 

The M unsignedNumber" is the number of octets to be 
recognized as characters. 

5.3.2 Executed Objects 

Bit 

A bit obeys these rules, which individually encode 
the bit's values: 

BitZero : : = tag 
BitOne : : = tag 



BitStrina 

A bit string obeys these rules: 

BitString ::= tag unsignedNumber unsignedNumber 
Octets 

Octets [octet Octets] 



The first "unsignedNumber" is the number- -in the 
range [1, 8] --of bits of the bit string in the last octet; 
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the other bits in that octet have no significance and are 
undefined. The second "unsignedNumber" is the number, 
"n", of occurrences of the token "octet" in the token 
"Octets". If the octets are numbered in [1, n] , the bit 
5 whose position in the bit string is "i" is Bit (7-(<i-l) 
mod 3)) of the octet numbered (ir(i-i)/e). 

Boolean 

A boolean obeys these rules, which individually 
encode the boolean' s values: 
0 BooleanFalse :: = tac 

Boolean True ::= tag 

Character 

A character obeys these rules. A general and a 
special encoding are defined. The latter shall be used 
5 for eight-bit characters: 

Character ::= GeneraiCharacter j 
SpecialCharacter 

GeneraiCharacter ::= tag octet octet 

SpecialCharacter :: = tag octet 

3 The one or two octets encode unsigned the integer 

that is the character's Unicode code. In the special 
encoding, the MS 3 and LSB of the integer are those of the 
octet. In the general encoding, the MSB and LSB of the 
integer are the MSB of the first octet and the LSB of the 

j second, respectively. 

Identifier 

An identifier obeys these rules. One general and two 

special encodings are defined. One of the latter shall be 

used iff the text of the identifier equals that of the 
identifier of a predefined class cr feature: 
Identifier ::= GenerallD | 

Predef inedClassID ! 
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GenerallD 
Predef inedClassID 
Predef inedFeaturelD 



Predef inedFe at ure ID 
= tag unsignedNumber characters 
= tag unsignedNumber 
= tag unsignedNumber 



10 
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5 In the general encoding, "unsignedNumber" and 

"characters" represent the text directly. The former is 
the number of octets to be recognized as the latter. In a 
special encoding, "unsignedNumber" represents the 
identifier's text indirectly, by a code drawn from one cf 
10 the tables in section 5.4. 
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Integer 

An integer obeys these rules. One general ana 

several special encodings are defined. The latter shall 

be used for -1, 0, and +1: 
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Integer 
General Integer 
Speciallnteger 



IntegerMinusCne 
IntegerZero 
IntegerPlusOne 



Generallnteger | Speciallnteger 

tag signedNumber 

Intege r Mi nu sOne ] 

IntegerZero ] 

IntegerPlusOne 

tag 

tag 

tag 



The signedNumber is the integer. 
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Mark 

25 A mark obeys this rule: 

Mark ; : = tag 
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Modifier 

A modifier obeys these rules, which individually 
encode the modifier's values: 
30 Modif ierDemarcate ::= tag 
Modif ierGetClass ::= tag 
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Modif ierGet Property 
Modif ierGet Variable 
Modif ierMent ion 
Modifier Set At tribute 
Modi fie rSet Property 
Modif ier Set Variable 
Modif ierUseS tack 



- tag 

= tag 

= tag 

= tag 

= tag 

= tag 

= tag 



T5 
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Nil 

A nil obeys this rule: 
Nil : : = tag 
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Octet 

An octet obeys this rule: 
Octet ::= tag octet 

The MSB of "octet" represents Bit 7 of the octet, the 
15 LSB Bit 0. 
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OctetString 

An octet string obeys these rules: 

OctetString ::= tag unsignedNumber Octets 

Octets ::= [octet Octets] 

20 The "unsignedNumber" is the number of occurrences of 

"octet" in "Octets". The first "octet" in "Octets" 
represents the octet at position one of the octet string, 
the second "octet" that at position two, etc. The MSB of 
each "octet" represents Bit 7 of that octet, the LSB 

25 represents Bit 0. 

Procedure 

A procedure obeys this rule: 

Procedure ::= tag unsignedNumber 3ody 



50 
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The "unsignedNumber" encodes the number of 
occurrences of "ExecutedOb ject " in n 3ody n , each of which 
encodes an item of the procedure. The items are given in 
order of increasing position within the procedure. 

Quai if iedldentif ier 

A qualified identifier obeys this rule: 

Qldentifier ::= tag Identifier Identifier 

The first "Identifier" represents the text, the 
second represents the qualifier. 

Real 

A real obeys this rule: 

Real ::- tag signedNumber signedNumber 

The first "signedNumber" is a mantissa, "m", the 
second 

an exponent, "e". The real is m x 10 c . 



Selector 

A selector obeys these rules, which individually 
encode the selector's values: 



SelectorBreak : 


:= tag 


Selector Client : 


: = tag 


Selector Continue : 


■= tag 


Selector Escalate : 


= tag 


Selector Place : 


= tag 


Selector Process : 


= tag 


Selector Self : 


= tag 


Selector Succeed : : 


= tag 



String 

A string obeys this rule: 

String ::= tag un signedNumber characters 
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10 



25 



The "unsignedNumber" is the number of octets to be 
recognized as characters. The syntax and semantics of the 
octets shall conform to ISO/IEC 10646 [10646] compaction 
method 5, except chat the characters thereby represented 
5 shall be limited to those of Unicode. 

Note : If the string comprises only ASCII characters, 

"characters" comprises their ASCII 
representations, one character per octet, 3it 7 
15 of each octet being zero. 

10 5.3.3 Other Non- terminals 

characters 
20 Zero or more octets. 

number 

From one to five, "N" , octets encoding an integer, 
15 "I". The encoding, " E " , of "I" is either unsigned, if the 
use of number insists that "I" be non-negative, or twos 
complement, otherwise. Given "I", "N" shall be as small 
as possible. 

" E " is determined as follows. 
20 • If the value of the first octet is in the range of 
[C, BF I6 ] , " N" is one and the MS3 and LSB of " E " are 
Bit 7 and Bit 0 of that sole octet . 

• If the first octet is E0 1(S , E2, 6 , E4 l6 , or E6, 6 , "N" is 

2, 3, 4, or 5 and the MSB and LSB of "E" would be Bit 
25 7 of the first octet and 3it 0 of the last octet if 

40 the first octet were made 00 (6 . 

• If the first octet is El l6 , E3 I6 , .ES I6 , or E7 1(j , n is 2, 

3, 4, or 5 and the MSB and LSB of "E" would be 3it 7 
of the first octet and Bit 0 of the last octet if the 

30 first octet were made FF, 6 . 

Note: The first octet's values in the ranges of [C0, 6 , 

DF 16 ] and [E8 l(i , FF,J are reserved. 



30 
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50 



octet 
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One octet . 



sianedNumber 

"number", where "I" can be positive or negative, and 
thus where "E" is signed (see above) . 
5 Note : If "N" is one, "I" is in the range [-64, 127] . 

If "N" is two, "I" is in the range [-12S, 127] . 
If "N" is three, "I" is in the range [-32763, 
32767] . If "N" is four, "I" is in the range 
[-8338608, 8388607]. If "N" is five, "I" is in 
.0 the range [-2147433648, 2147483647] . 



tag 

"signedNumber" , where the tag's meanings are given in 
the next section. 

uns icmedNumber 

5 "number", where "I" is non-negative, and thus "E" is 

unsigned (see above} . 

Mote: If "N" is one, "I" is in the range [0, 191]. If 

"N" is two, "I" is in the range [0, 255] . If 
n N M is three, "I" is in the range [0, 55535] . 
0 If »N" is four, "I" is in the range [0, 

16777215] . If " N " is five, "I" is in the range 
[0, 4294967295] . 

5 . 4 Numeric Codes 

Binary telescripts make use of the following numeric 
5 codes . 



5.4.1 Predefined Classes 

Table A. 7 assigns identifier codes to the predefined 
subclasses of class "Executed" . 



TABLE A. 7 
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10 



45 



1 


3i t 




Bit St ring 


~i 
J 


Boolean 




Charac t e r 


5 


Identifier 


c 


Integer 


t 


Mark 


a 
O 


Med i tier 




Nil 


10 


vJC vSt 


11 


OctetString 


12 


Procedure 


13 


Qldent i f ier 


14 


Real 


1 5 


Selector 


16 


String 


Table A. 3 assigns identifier codes to the other major 
predefined classes. 


TABLE 1.3 


20 


Agent 


21 


Association 


22 


Attribute 


23 . 


Authencicator 
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5 







24 


CalendarTime 






2 5 


Cased 


10 




26 


Citation 






2 7 


Cited 






28 


Class 


15 




2 9 


ClassDef inition 






3 0 


Class Except: ion 


20 




3 1 


Collection 




32 


ColleccionExcept ion 






3 3 


Constrained 


25 




34 


Constrair.edDictionary 






35 


Const rainedList 






36 


ConstrainedSet 


30 




3 7 


Constraint 




la 


33 


Contact 






3 9 


Contacted 


35 




4 C 


Dictionary 






41 








42 


Executed 


40 


20 


43 


Execut ionException 






44 








45 


Feature 


45 




4 6 


Hashed 






47 


Implementat ion 
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5 







48 


Interchanged 






45 


Interface 


10 




50 


KernelSxception 






51 


Lexicon 


15 


5 


52 


List 




53 


Means 






54 


Meet ingExcept ion 


20 




55 


MeetingPlace 




56 


Method 




10 


57 


MisceilaneousException 


25 




53 


Named 






59 


Number 






60 


Object 


30 




61 


Operation 




15 


62 


Ordered 






63 


Package 


35 




64 


Pattern 






- D 


Permit 






66 


Petition 


40 


2 0 


67 


Petitioned 






63 


Place 






69 


Primitive 


45 




70 


Primi t ive Except ion 






71 


Process 
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72 



ProcessExcepc ion 



Prograrcmir.gSxcept ion 



RandomStream 



75 



Referenced 



73 



Resource 



30 



SI 



itaCK 



Stream 



33 



Teieaddress 



84 



Telen 



85 



Tele number 



36 



Ticket 



87 



TicketStub 



36 



Tin 



85 



TripException 



90 



Unchanged 



91 



UnexpectedExcept ion 



92 



Unmoved 



93 



Verified 



94 



Way 



Table A . 9 assigns identifier codes to the 
j predefined classes. 
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5 




TABLE A. 9 






100 


Permic Inadequate 


10 




101 


Argurr.e n 1 1 nva 1 i d 






102 


ArgunentMissing 




- 


103 


Ate r ibuceReadOaly 


15 




104 


ClassAbsc ract 






105 


CI assUnavai lable 






106 


C 1 a s sUnde f i ned 


20 




107 


ClassSealed 




1 0 


103 


Condi tionUnava liable 


25 




1C9 


Condi t ionUnde f i ned 






110 


Cor.ver s ionUn avail able 






111 


CcpyUnava liable 


30 




112 


Des~ inat icnUnavai lable 




i r 


113 


Desz inat ionUnkncwn 






114 


DivisionByZero 


35 




115 


- 






116 


Escalat ion I aval id 






117 


FeatureRede f ined 


40 


20 


118 


F eatureSeaied 






119 


FeatureUnavai lable 






120 


FeatureUnde fined 


45 




121 


InternalExcept ion 






122 


I temDuplicated 



55 



331 



EP 0 634 719 A2 







123 


Itemlnvaiid 






124 


KeyDupl i cared 




10 




125 


Keylnvalid 






126 


LoopMissing 




5 


127 


MarkMissing 


15 




128 


Meet ingDenied 








129 


Meet ingDup Ilea zed 






130 


Meeting I nv a 1 i d 


20 




131 


MixinDi sal lowed 






10 


132 


Ob j ectsUnpaired 


25 




133 


Ob ject Uninitialized 






134 


OccupanyDenied 






135 


Passage Ir.val id 


30 




136 


Patternlnvalid 




1 5 


137 


Permit Exhausted 






13S 


PermitViolated 


35 




139 


Pet itionExpired 






140 


Posit ionlnva lid 






141 


ProcessMot Current 


40 


20 


142 


ProcessNotPeer 






143 


PropertyUnde fined 






144 


Reference Protected 


45 




14 . 


Re f erenceVoid 






146 


ResponderMiss ing 
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147 


Resultlnvalid 


148 


ResuitMissing 


149 


Selector Duplicated 


150 


StackDepleted 


151 


St ate Improper 


152 


Superclasses Inval id 


153 


TicketExpired 


154 


Variable Undefined 


155 


WayUnava liable 


179 


ResourceUnava liable 


i 

130 


Seedlnval id 


5.4.2 Predefined Features 


Table A. 10 assigns identifier codes to the predefined 
operat icns . 


TABLE A. 10 


1 


abs 


2 


add 


3 


adj ust 


4 


and 


5 


catch 


b 


cei 1 ing 


7 


charge 


8 


clear 
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TABLE A. 10 


9 


convert 


10 


copy 


1 1 


d i f f 6 rence 


12 


■discard 


13 


divide 


14 


do 


15 


drop 


16 


either 


17 


entering 


18 


examine 


19 


exclude 


20 


exiting 


21 


finalize 


22 


f ind 


23 


floor 






25 


globalize 


26 


go 


27 


if 


23 


include 


29 


initialize 


30 


intersection 


31 


interval 
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TA3LE A. 10 


32 


isAf csr 


33 


is3efcre 


34 


isEgua I 


3 5 


i s Instance 


3 6 


i s Member 


37 


i s Same 


3 8 


isSubciass 


39 


I i ve 


4 0 


loca 1 i ze 


4 1 


Iccc 


42 


ma keCl asses 


43 


rnakeLower 


44 


makeUppe r 


45 


meet 


46 


mee t ing 


4 7 


modulus 


43 


multiply 


4 9 


negate 


50 


new 


51 


norma 1 ize 


52 


not 


53 


or 


54 


part 
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TABLE A. 10 


55 


part All 


56 


part ing 


57 


pop 


5S 


protect 


59 


push 


60 


pushltems 


61 


quotient 


62 


ref 


63 


rekey 


64 


repeat 


65 


reposition 


66 


restrict 


67 


roll 


63 


round 


69 


select 


70 


send 


71 


sec 


72 


stream 


73 


substitute 


74 


substring 


75 


subtract 


76 


swap 


77 


terminate 
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5 



15 



20 



7 A3 Li E A. 10 


78 


throw 


79 


transpose 


80 


truncate 


8 1 


un ion 


82 


use 


83 


verify 


84 


wait 


35 


whi le 


86 


max 


37 


min 


Table A. 11 assigns identifier cedes to the predefined 
attributes. 


TABLE A. 11 


89 


address 


90 


agentClass 


91 


agentName 


92 


al lowance 


9 3 


arguments 


94 


authent icator 


95 


author 


96 


authori ty 


97 


brand 
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5 




TABLE A. 11 






99 


canCharge 


10 




99 


canGo 






100 


canProcreace 






101 


canRestart 


15 


5 


102 


canS end 






103 


canTeoinate 






104 


citation 


20 




105 


class 






10$ 


classreatures 


25 


10 


107 


classld 




103 


classMethods 






109 


condition 


30 




110 


conditions 






111 


constraint. 




15 


112 


contacts 


35 




113 


country 






114 


current 






115 


day 


40 






dayOf Week 




20 


117 


dayOf Year 


45 




118 


deadline 




119 


desi redWai t 






120 


dest inationAddress 
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TABLE A. 11 


121 


dest ir.at ionClass 


122 


de s t i na t i onName 


123 


dest inat icnPermi t 


124 


digest 


125 


dst 


126 


exception 


127 


except ions 


123 


extension 


129 


f romMethcds 


130 


hash 


131 


hour 


132 


i dent icy 


133 


i implementation 


13 4 


instance Features 


135 


ins tanceMet hods 


136 


interface 


137 


isAbstract 


133 


is Done 


139 


is Lower 


140 


isOpt ional 


141 


isPrctected 


142 


isFublic 


143 


isSet 
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5 







TA3LE A. 11 






144 


isUpDer 


10 




145 








146 


1 e n<jc H 


15 




147 




5 


14S 


H -C3. J W a. Cj ^* -L I- J- l_> i 1 






14 9 


m a v "i tii t.Wa *> t~ 


20 




150 








151 








152 


TlinUw6 


25 


iC 


153 


mo n h 






154 


n mo 






155 


nsxc 


30 




156 


or wlsss 






157 


yds odO S 


35 


1 5 


153 


permit | 




159 


priority 






160 


privateClasses 


40 




161 


procedure | 






162 


prcpert ies 




20 


163 


provider 


45 




164 


pubLicClasses 






165 


result 






166 


roue ir.gAdvice 
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TArLE A. 11 


1S7 


seal edCI ass Features 


163 


sea led Instance Features 


169 


setMethcds 


170 


second 


171 


size 


172 


subject 


173 


subj ectClass 


174 


subj ectName 


175 


subj ectNoces 


176 


superclasses 


177 


telephone 


173 


ticketStub 


179 


title 


130 


toMethods 


131 


travelNotes 


132 


value 


133 


variables 


1S4 


vocabulary 


185 


way 


186 


year 


137 


zone 



Note : "islnstance" is not listed as an attribute 

because it is also an coeration. 



50 
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Table A. 12 assigns codes to the forns of passage. 



TABLE A. 12 




191 


byCopy 




192 


byProtectedRe Z 




193 


byRef 




194 


byUnprotectedRef 




5.4.3 Executed 


Obi ect Encodings 




Table A. 13 assigns codes to general -purpose 
encodings . 




A. 13 






2 


BitString 


3 




4 


Genera ICharacter 


5 


Identifier 


c 


General Integer 


7 


Mark 


3 




9 


Nil 


10 


Octet 


11 


OctetString 


12 


Procedure 


13 


Qualifiedldentifier 
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TABLE A. 13 


14 


Real 


15 




16 


String 


Note : These tags are the codes for the corresponding 
predefined classes. 

Table A. 14 assigns codes to special -purpose encodings 
cf a basic nature. 


TABLE A. 14 


0 


Comment 


-1 


3itZero 


-2 


BitOne 


-3 


BooleanFaise 


-4 


BooleanTrue 




SpeciaiCharacter 


- o 


Fredef inedClass I dent i f ier 


-7 


Predef inedFeature Identifier 


-3 


I ntece rMinusOne 


-9 


Integer Zero 


-10 


IntegerPiusOne 



Table A. 15 assigns codes to special -purpose encodings 
of modifiers. 



TA3LE A. 15 
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J. J 


noc l i- i e rue w ^_ jl a s s 


- 14 


Mr H i H o rOpr 3rnr,p >- r v 


-15 


Modi rierGet Variable 


-16 


Modi fierMent ion- 


-17 


Modi fierSet At tribute 


-18 


ModifierSet Property 


-19 


Modi fierSet Variable 


-20 


Modifier Use Stack 


Table A. 16 assigns codes tc special -purpose encodings 
of selectors. 


TA3L2 A. 16 


-21 


SeiectorBreak 


-22 


SelectorClient 


-23 


Select or Continue 


-24 


Selector Escalate 


- 25 


SeiectorPlace 


-26 


Selector Process 


-27 


SeiectcrSel f 


-23 


Selectors ucceed 



6 Syntax of Module 

A "module", as the term is used here, is a string 
that encodes one or more interfaces, the identifiers of 
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the classes of which "hose interfaces are parts, and, 
finally, an identifier for the module itself. 

Throughout Section 6, the term "identifier" 
implicitly refers to the text of an instance of class 
"Identifier", rather than to the instance as a whole. 
Note : A module constructed as described below is a 

High Telescript module as well. Any rule below 
that makes this statement false is a 
documentation error. 

6 . 1 General Structure 

A module is a series of tokens obeying the syntactic 
and accompanying semantic, rules below. Given in BNF, th 
rules surround optional tokens by brackets (" [" and "] "} . 
In addition, a module can include comments of the sort 
permitted in a character telescript. The provision for 
such comments is considered among the syntactic rules 
governing the module. 

Each token is one cr more characters. The module is 
obtained by concatenating the tokens, and thus the 
characters, and by inserting between tokens break 
characters of the sort permitted in a character 
telescript . 

Keywords, e.g., "module", are case-sensitive. While 
upper-case characters are used below to describe modules 
in general, lower-case characters are used in Section 7 
and throughout this appendix to construct a module. 

6 . 2 Detailed Structure 

A module exhibits the following detailed structure. 

6.2.1 Module 
Module 

A module obeys these rules: 

Module identifier : MODULE = 

( Interfaces) 
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Interfaces ::= identifier : Interface; 
[Interfaces] 



The module is denoted by the identifier that begins 
the module, and encodes the interfaces, each that of the 
5 class whose identifier immediately precedes the 
ident if ier . 

Any interface can define operation "initialize" as 
pertains to members of the interface's particular class. 
A definition is implied, furthermore, if none is stated: 
0 either "initialize: op ();", if the class in question is 
mix-in, or the definition for the flavor among the class 
interface superclasses , otherwise . 



6.2.2 Interface 
Interface 
5 An interface obeys 

Interface : : = 



) 

0 Formal Parameters 

Formal ParameterStoup 
Superclasses 
Definitions 
Def in it ionGroup 

5 

Access 
Responder 
Identifiers 
Definition 

0 Feature 



these rules : 
[SEALED | ABSTRACT] INTERFACE 
" [ " FormalParameters " ] " 1 
[Superclasses] = ( [Definitions 

ParameterGroup [ ; 

Identifiers : CLASS 

( [ClassSpecif iers] ) 

Def init ionGroup ; [Definitions] 

[Access] [Responder] 

Identifiers : Definition 

PUBLIC ! PRIVATE | SYSTEM 

INSTANCE | CLASS 

identifier [, Identifiers] 

SEALED | [SEALED ] ABSTRACT] 



An interface's encoding can be parameterized. In 
such an encoding, one or more "formal class parameters", 
each an identifier, are introduced, and can be used in 
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most places the interface requires class identifiers (see 
token "ClassSpecif ier" below) . The interface is as if the 
identifier of class "Object" were used instead. Formal 
class parameters defined alike are grouped at their 
introduction . 

Zero or more features, each denoted by an identifier, 
are sealed or defined. The identifiers cf features sealed 
or defined alike are grouped. If "Access" or "Responder" 
is absent from the first such group, "PRIVATE" or 
"INSTANCE", respectively, shall be considered present 
there. If "Access" or "Responder" is absent from any 
subsequent group, the keyword present in the previous 
group shall be considered present in the subsequent group. 

The interface is this. The "classFeatures " or 
" instanceFeatures " attribute comprises the features 
defined in groups with "CLASS" or " INSTANCE" , 
respectively. The " isAbstract " attribute is "true" iff 
"ABSTRACT" is present. The " sealedClassFeatures" or 
"sealedlnstanceFeatures" attribute comprises the 
identifiers in groups with both "SEALED" and " CLASS" or 
"INSTANCE", respectively. The "superclasses" attribute 
comprises either the identifiers token "Superclasses" 
determines, if the latter is present, or the identifier of 
Class "Object" only, otherwise. The positions in the 
attribute of the classes decrease as their specifiers move 
from left to right. The "vocabulary" attribute is 
cleared . 

The interface is sealed iff " SEALED" is present. 

5.2.3 Feature 
Feature 

A feature definition obeys this rule: 

Feature ::= Attribute | Operation 

Attribute 

An attribute definition obeys this rule: 
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Attribute ::= [READONLY] Constraint 
[THROWS Identifiers] 
The attribute definition is this. The "constraint" 
attribute is the constraint given. The "exceptions" 
5 attribute comprises either the identifiers present, if 
" THROWS " is present, or no identifiers, otherwise. The 
"isPublic" attribute is "true" iff che key for the 
definition group that includes the attribute definition is 
" PUBLIC " or "CLASS" . The "isSet" attribute is true iff 
0 " READONLY " is absent. 

A module's encoding, as defined above, of an 
attribute definition is sometimes called the signature of 
the attribute it defines. 

Operation 

5 An operation definition obeys this rule: 

Operation ::= [UNPROTECTED] op ( 

Argument sAt tribute) 
[Constraint] [THROWS Identifiers] 
The operation definition is this. The "arguments" 
0 attribute is as given. The "exceptions" attribute 

ccmprises either the identifiers present, if "THROWS" is 
present, or no identifiers, otherwise. However, iff 
" UNPROTECTED " is present, the attribute comprises, 
additionally, the identifier for class "Reference 
5 Protected", which is thrown if the operation, which 
modifies the responder, is requested using a protected 
reference to the responder. The "isPublic" attribute is 
"true" iff the key for the definition group that includes 
the operation definition is "PUBLIC" or "CLASS" {see tcken 
0 "Interface" above) . The "result" attribute is either the 
constraint, if one is present, or a nil, otherwise. 

A module's encoding, as defined above, of an 
operation definition is sometimes called the signature of 
the operation the operation definition defines. 
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Arguments At tribute 

An "arguments" attribute obeys these rules: 
ArgumentsAttribute ::= [Arguments] [...] 

Arguments ::= Argument: Group [ ; Arguments] 
5 ArgumentGroup Identifiers : Constraint 



Zero or more arguments are described by their 
constraints. Each such argument is denoted by an 
identifier. The identifiers of arguments constrained 
alike are grouped. If both one or more argument groups 
0 and the ellipsis (...) are present, the last group shall 
comprise just cne argument, but shall be considered to 
comprise zero cr more arguments. 

The "arguments" attribute is either a list of the 
constraints upon the zero or more described arguments, if 
5 the ellipsis (...) is absent, or a nil, otherwise. The 
positions, in the list, of the constraints upon the 
described arguments increase as their identifiers move 
from left to right. 



6.2.4 Constraint 
Const ra int 

A constraint obeys these rules: 

Constraint ::= [COPIED \ PROTECTED | 

UNPROTECTED] ClassSpecif ier [ " | " 
NIL] 



The constraint is this. The "classld" attribute is 
the identifier that token "ClassSpecif ier" determines. 
The "islnstance" attribute is "true" iff the exclamation 
mark ( " ! " ) is present within token "ClassSpecif ier" (see 
below) . The "isOptional" attribute is "true" iff "NIL" is 
present. The "ofClass" attribute is a nil. The "passage" 
attribute is "byCopy" , "byProtectedRef " , 
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"byUnprotectedRef " , or "byRef" if "COPIED" , 11 PROTECTED" 
"UNPROTECTED", or none of these, respectively, is present. 

ClassSoeci f ier 

A class specifier obeys these rules: 
ClassSpecif ier identifier [!] 

[" [•' ClassSpecif iers "]«] 
ClassSpecif iers ::= ClassSpecif ier [, 
CI ass Spec i f iers] 

The identifier is that of either a formal class 
0 parameter or a class, "C". In the latter case, iff the 
encoding, "E" , of the interface of "C" is parameterized, 
there fellow, between square brackets ( " [ " and "J"), as 
many actual class parameters, each a class specifier, as 
"C" has formal class parameters. This particular use of 
5 "C" is as if each use of a formal class parameter within 
"E" were a use cf the correspondingly positioned actual 
class parameter. 

6.2.5 Other Non- terminals 

identifier 

0 Characters constrained as is the text of an instance 

of class "Identifier". 

7 PREDEFINED MODULE 

The interfaces to the predefined classes are defined 
by a module which appears in full below and in fragments 
5 throughout this appendix. The Instruction Set's internal 
features do not appear in the module. 

This Section, i.e. Section 7, provided for reference 
purposes, duplicates material found elsewhere in this 
appendix . 

0 Note: The predefined interface definitions form a High 

Telescript module. To make this possible, 
certain Low Telescript identifiers are pestfixed 
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with "_x" to avoid identifiers that are reserved 
words in High Teiescript . 



module = ( 

abstract interface (Process) = ( 
private 

go: unprotected op (ticket: copied 

Ticket) TicketStub 
throws PermitViolated, 

State Improper, TripException; 

send : unprotected op (tickets: 
copied List [Ticket] } 
TickecstubjNil 
throws PermitViolated, 

S t at elmp roper , TripException; 

> /* 

Association: sealed interface [keyClass, vaiueClass : 

Class] (Object, Ordered} = ( 
public 

key : keyClass ; 

value : vaiueClass ; 
system 

initialize: unprotected op ( 
key: keyClass; 
value: vaiueClass) ; 

) ; 

Attribute: sealed interface (Feature) = ( 
public 

constraint: Constraint; 

isSet: Boolean; 



Teiescript : 
Agent : 
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system 

initialize: unprotected op ( 
constraint : Constraint j Nil ; 
isSet, isPublic: Boolean j Nil ; 
exceptions: Set 

[Identifier! ] jNil) ; 

} ; 

Authenticator : abstract interface = (); 

Bit: sealed interface (Primitive, Ordered) 



0 ; 



BitString: sealed interface (ConstrainedList 
[Bit] , Executed) = ( 
public 

constraint : sealed; 

system 

initialize: unprotected op 
(segments: Object ... 
/* Bit | protected BitString! */) ; 

) ; 

Boolean: sealed interface (Primitive, Ordered) 
( public 

and, or: op (boolean: Boolean) 



Boolean; 



not: op {) Boolean; 

) ; 



CalendarTime : interface = ( 

public 
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O ; 



Boolean ; 



day, dst, hour, minuce, month, 
second, year, zone: 
Integer | Nil ; 

dayOfWeek, dayOfYear: readonly 
Integer | Nil ; 

globalize, local ize : unprotected op 



normalize: unprotected op () 

) ; 

Cased: abstract interface {) = ( 
public 

isLower, isUpper: abstract 
readonly Boolean; 

makeLower, makeUpper: abstract op 
{) copied Cased ; 

) ; 



Character: sealed interface (Primitive, Cased, 
Ordered) = { ) ; 

Citation: interface (Object, Ordered) = ( 
public 

author: Telename [Nil ; 



nteger J Nil ; 



majorEdition, minorEdi t icn : 



title: Identifier!; 
system 

initialize: unprotected op { 
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tide : Identifier ! ; 
author : Telename J Nil ; 
ma j or Edit ion, minorEdition : 
Integer j Nil) ; 

) ; 

Cited: abstract interface 0 = ( 
public 

citation: readonly protected 

Citation; 
10 system 

initialize: unprotected op ( 
title : Identifier ! ; 
ma j orEd i t ion , minorEdi t ion : 
Integer) / 

15 ) ; 

Class: sealed interface (Object, 
Cited, Interchanged) = ( 
public 

convert: sealed op (source: 
20 protected Object) 

copied Object 
throws ConversionUnavailable; 

islnstance: sealed op (instance_x: 
protected Object) Boolean; 

25 isMember: sealed op (member: 

protected Object) Boolean; 

isSubclass: sealed op (subclass: 
Class) Boolean; 
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new: sealed op (parameters: Object 
. . . ) Object 
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throws ClassAhscract , Exception, 
Ob jectUninit ialized; 



system 



initialize: unprotected op () 
throws FeatureUnavailabie; 



) ; 



15 



ClassDef inition : sealed interface = ( 

public 

implementation : 

10 Implementation ] Nil ; 



20 



interface x: Interface; 



25 



30 



Integer; 



15 



ma jorEditicn, minorEdition : 



nakeClasses : op (definitions: 
protected ClassDef inition . 
Lexicon [Class] 

:hrows ClassExcept ion; 
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minorEdition: Inteaer; 



Implementation [Nil) ; 

) ; 



title: Identifier! ; 
system 

initialize; unprotected op (title; 
Identifier I ; 
m'ajorEdition, 

interface_x: Interface; 
implementation : 
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55 



355 



EP0 634 719 A2 



10 



15 



20 



25 



30 



35 



40 



45 



50 30 



55 



ClassSealed : interface ( ClassExcept ion) 

= 0 ; 

CiassUndef ined : interface 
(ClassExcept ion) =(); 

reatureRedef ined : 

interface (ClassExcept ion) = (); 
FeatureSealed : interface 

(ClassException) = (); 
Feat ureUnde fined : 
10 interface (ClassException) = (); 

MixinDisal lowed : 

interface (ClassException) = !); 
Superclasses Invalid: 

interface (ClassException) = (); 

15 Collection: interface [itemClass: Class] ={ 

public 

clear: unprotected op (); 

examine: op (item: protected 
itemClass) itemClass [Nil ; 

exclude: unprotected op (item: 
protected itemClass) 
itemClass J Nil ; 

include: unprotected op (item: 

throws I temlnvalid; 
length: readonly Integer ; 

stream: op () copied Stream 
[itemClass] ; 

system 

initialize: unprotected op (items: 
itemClass . . . ) 



20 



itemClass J 
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throws Itemlnvalid; 

) ; 

Collection abstract interface 
(ProgrammingException) = (); 
5 Exception: ItemDuplicated : 

interface (CollectionException) = () 
Itemlnvalid: 

interface ' (CollectionException) = ( ) 
KeyDupl icated : 

10 interface (CollectionException) =() 

Keylnvalid : 

interface (CollectionException) = ( ) 
Obj ectsUnpaired : 

interface (CollectionException) = () 
15 Positionlnvalid : 

interface (CollectionException) = () 
StackDepleted: 

interface (CollectionException) = () 

Constrained: abstract interface () = ( 
20 public 

constraint : 
readonly protected Constraint; 
system 

initialize: unprotected op ( 
25 constraint: copied 



Constraint jNil) ; 



) ; 



45 Constrained interface [keyClass, valueClass: Class] 

Dictioncary: (Dictionary [keyClass, valueClass] , 

Constrained) = ( 
system 

initialize: unprotected op ( 

constraint: copied Constraint; 

55 
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keysAndValues : Object ... 
/* key: keyClass; value: 
valueClass */) 
throws KeyDuplicated, Keylnvalid, 
ObjectsUnpaired; 



10 



ConstrainedList : * interface [itemClass: Class] (List 

[itemClass] , Constrained) = { 
15 system 

initialize: unprotected op ( 
constraint: copied Constraint; 
items: itemClass . . . ) 
throws Itemlnvalid; 
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25 ConstrainedSet : interface [itemClass: Class] 

(Set [itemClass] , Constrained) = ( 
system 

initialize: unprotected cp ( 

constraint: copied Constraint; 
items: itemClass ...) 
throws ItemDuplicated, 
Itemlnvalid; 
) ; 

40 Constraint : interface = ( 

public 

classld: Identifier! ; 

islnstance, isOptional: Boolean; 
of Class: readonly Class j Nil; 
passage : Identifier! 
throws Passagelnvalid; 
system 

initialize: unprotected op ( 
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Identifier! I Nil, 



BooleanlNil) 



classld, passage: 



isOptional , islnstance : 



throws Passage Invalid; 



) ; 
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Contact : interface = ( 
public 

subject : Process ! Nil ; 

subj ectClass : readonly protected 

CitationjNil; 
subjectName: readonly protected 

Telename j Nil ; 
sub j ectNotes : ObjectjNil; 

system 

initialize: unprotected op ( 
subject : Process [Nil; 
subjectNotes : ObjectjNil) 

) ; 

Contacted: abstract interface () = ( 
private 

contacts: readonly Set [Contact]; 

) ; 



*o Dictionary: interface (keyClass, valueClass: Class] 

25 (Set [Association [keyClass, 

valueClass] ] ) = ( 
public 

45 

add: unprotected op (key: keyClass ; 
value : valueClass) 
3C throws Keylnvalid; 
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drop: unprotected op (key: protected 

keyClass) valued ass 
throws Key Invalid ; 

find: op (value: protected 
valueClass) keyClass j Nil ; 

get: op (key: protected keyClass) 

valueClass 
throws Key Invalid ; 

rekey: unprotected op ( 

currentKey: protected keyClass ; 

newKey: keyClass) 
throws Key Invalid; 

sen : unprotected op ( 

key: protected keyClass; 

value : valueClass) 

x 

throws Xeylnvalid; 

transpose: unprotected op (keyl, 

key2 : protected keyClass) 
throws key Invalid; 
system 

initialize: unprotected op 
(keysAndValues : Object . . . 
/* key: keyClass; value: valueClass */) 
throws KeyDuplicated, Keylnvalid, 

Obj ectsUnpaired; 

) ; 

abstract interface (Object, Unchanged) = 
(public 

throw_x: sealed op (); 

) ; 
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Executed: abstract interface () = { 
public 

catch_x: sealed op (exception; 

Class) Exception | Nil 
throws Except ion ; 

do_x, loop_x: sealed op () 
throws Exception ,- 

either: sealed op (false_x: 
Executed; precondition: Boolean) 
throws Exception ; 

if_x: sealed op (precondition: ■ 
Boolean) 

throws Exception; 

repeat_x: sealed op {repetitions 
Integer) 

throws Exception; 

while_x: sealed op (precondition 
Executed) 

throws Exception, Result Invalid, 
ResultMissing; 

) ; 

Execution . abstract interface (KernelExcept ion) = 
Exception : 

Argument Invalid : 

interface (ExecutionExcept ion) =() ; 
ArgumentMissing : 

interface (Execut ionException) = () ; 
AttributeReadOnly : interface 

(ExecutionExcept ion) = 0; 
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ClassUnava liable : 

interface (ExecutionException) = () 
Escalation I rival id : 

interface (ExecutionException) = () 
5 FeatureUnavailable : 

interface (ExecutionExcept ion) = () 
InternalException : 

interface (ExecutionExcept ion) = () 
is Property Undefined: 

10 interface (ExecutionException) = () 

Ref erenceProtected : 

interface (ExecutionExcept ion) = 0 
20 Ref erenceVoid : 

interface (ExecutionException) - () 
15 ResponderMissing : 

interface (ExecutionExcept ion) = () 
Result Invalid : 

interface (ExecutionException) = C) 
ResultMissing : 

20 interface {ExecutionException} = () 

VariabieUnde fined : 

interface (ExecutionException) = () 
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Feature: abstract interface = ( 
public 

25 exceptions: Set [Identifier!]; 

**o isPublic: Boolean; 

system 

initialize: unprotected op ( 
is Public : Boolean j Nil ; 
45 30 exceptions: Set 

[Identifier! ] j Nil) ; 



50 



Hashed: abstract interface () = ( 
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publ ic 

hash: abstract readonly Integer; 

) ; 

Identifier: sealed interface (Primitive, Ordered) = 



10 5 0 ; 



Implementation: sealed interface = { 

publ ic 

classMethcds, f romMethcds , 
instanceMethods , setMethods, 
!0 toMethods: Lexicon [Method] ; 

properties: List [Identifier!]; 



superclasses: List 
25 [Identifier!] |Nil; 

vocabulary: Lexicon 
15 [Citation] [Nil ; 

30 system 

initialize: unprotected op ( 
superclasses : List 
[Identifier! ] [Nil; 
2C ' vocabulary: Lexicon 

[Citation] [Nil; 
properties: List 
[Identifier! ] [Nil; 
instanceMethods , setMethods , ' 
25 ciassMechods, 

f romMethods, toMethods: Lexicon 
45 [Method] j Nil) ; 

) ; 

Integer: sealed interface (Number) = { 
50 3 0 oublic 



55 



363 



EP 0 634 719 A2 



modulus, quotient: op (divisor: 

Integer) Integer 
throws DivisionByZero; 

) ; 

Interchanged: abstract interface (Unchanged) = ( 

public 

digest: abstract readonly 
protected Object |Nil; 

) ; 

Interface: sealed interface = ( 
public 

classFeatures, instanceFeatures 
Lexicon [Feature] ,- 

isAbstract: Boolean; 

sealedClassFeatures, 

sealedlnstanceFeatures : 
Set [Identifier! ] ; 

superclasses: List [Identifier!] 

vocabulary: Lexicon [Citation] ; 
system 

initialize: unprotected op ( 
superclasses: List 
[Identifier!] ]Nil; 
vocabulary : Lexicon 
[Citation] [Nil; 
instanceFeatures : 

Lexicon [Feature] jNil; 
sealedlnstanceFeatures : 

Set [Identifier!] JNil; 
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classFeatures : Lexicon 
[Feature] jNil; 
sealedClassFeatures : 

Set [Identifier!] jNii; 
isAbstract : Boolean j Nil ) ; 



) ; 



Kernel 

Exception: abstract interface 

(ProgrammingException) = () ; 

10 ClassAbstract : interface 

(KernelException) = (); 

ConversionUnavailable : 

interface (KernelException) = (); 

CopyUnavailable : 
15 interface (KernelException) = {); 

LoopMissing : interface (KernelException) 

- O ; 

MarkMissing.- interface (KernelException) 

= O ; 

20 Obj ect Uninitialized: 

interface (KernelException) = ();• 

Passage I nval id : 

interface (KernelException) = (); 



Selector Duplicated : 

interface (KernelException) = () ; 

Lexicon: interface [valueClass: Class] 
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( Const rainedDictionary [ I dent if ier , 

valueClass] ) = ( 
public 

constraint: sealed; 
system 

initialize: unprotected op 

(keysAndValues : Object ... 
/* key: Identifier!; value: 

valueClass */) 
throws XeyDuplicated, Keylnvalid, 

ObjectsUnpaired; 

nterface [itemClass: Class] 

(Collection [itemClass] , Ordered) 

public 

add: unprotected op (position: 
Integer; item: itemClass) throws 
Itemlnvalid, Positionlnvalid; 

drop: unprotected op (position: 
Integer} itemClass 
throws Pos it ion Invalid ; 

find: op ( 

initial Pos it ion : Integer,- 
item: protected itemClass) 
Integer | Nil 

throws Positionlnvalid; 

get: op (position: Integer) 
itemClass 

throws Positionlnvalid; 
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reposition: unprotected op 

(currentPosicicn, newPosition : 
Integer) 
throws Posit ionlnvalid; 

set: unprotected op (position: 
Integer; item: itemCiass) throws 
Itemlnvalid, Posit ionlnvalid; 



transpose: unprotected op 
{posit icnl, position2: Integer) 
10 throws Positionlnvalid; 

20 system 

initialize: unprotected op (items 
itemCiass . . . ) ; 

) ; 



15 Mark: sealed interface (Primitive) = () ; 

Means: abstract interface = () ; 

MeetingSxception: abstract interface (Exception) = () ; 

35 Meet ingDenied : 

interface (Meet ingException) = (); 
20 Meet incDupIicated : 

interface (Meet ingException) = ( ) 
Meet ing In valid : 

interface (Meet ingExcept ion) = () 
Petit icnExpi red : 

25 interface (Meet ingException) = () 



MeetingPlace : abstract interface (Place) = ( 

oublic 
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meet: unprotecte ' op (petition 
copied Petition) Contact 

throws MeetingException, 
ProcessNotCurrent , 
Statelmproper ; 

part: unprotected op (contact: 
Contact ) 

throws Meetinglnvalid, 
ProcessNotCurrent , 
S t ace Improper ; 

partAll: unprotected op (} 
throws ProcessNotCurrent , 
Statelmproper ; 



Method: sealed interface = { 
pubi ic 

procedure : Procedure ; 

variables: List [Identifier!; 
system 

initialize: unprotected op ( 
procedure: Procedure J Nil ; 
variables: List 

[Identifier ! ] J Nil) / 

) ; 

Miscellaneous abstract interface 

(FrogranmingExcepcion) = (); 

Exception : 

Patternlnvalid: interface 

(MiscellaneousExcepticn) = () ; 
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Seedlnvalid : 

interface (MiscellaneousException) 



Modifier: sealed interface (Primitive) = <); 

Named: abstract interface () = ( 
public 

name : sealed readonly protected 



is Telename; 



Nil: sealed interface (Primitive) = (); 



Number: abstract interface (Primitive, Ordered) 
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Numbe r ; 



public 

abs, negate: abstract op {] 



add, multiply: abstract op 
(number: Number) Number ,- 

ceiling, floor, round, truncate: 
abstract op () Integer; 
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divide: abstract op (divisor: 

Number) Number 
throws DivisionByZero ; 

subtract: abstract op (subtrahend: 
Number) Number; 



; ; 



Object: abstract interface (Referenced) = ( 
public 
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class: sealed readonly Class; 
copy: sealed op () copied Object 

throws CopyUnavailable ; 

isEqual : op (object: protected 
Object) Boolean; 

select: sealed op (associations: 
Object; . . . 

/* protected Object; Executed 
*/) 

throws Exception, 

Selector/Duplicated; 

size: sealed readonly Integer; 
system 

finalize, initialize: unprotected 

op ( ) ; 

) ; 

Octet: sealed interface (Primitive, Ordered) = 



0 ; 



OctetString: sealed interface (ConstrainedList 

40 

<* u [Octet] , Executed) = ( 

publ ic 

constraint : sealed; 
45 system 



25 



initialize: unprotected op 
(segments: Object ... 
/* Octet Jprotected OctetString! 
*/) ; 



/ ; 
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Operation: sealed interface (Feature) - ( 
public 

arguments: List [Constraint] jN 

result : Constraint j Nil ; 
system 

initialize: unprotected op ( 
arguments: List 

[Constraint] j Nil ; 

result : Constraint | Nil ; 
isPublic : Boolean [ Nil ; 
exceptions: Set 

[Identifier! ] ]Nii) ; 

) ; 

Ordered: abs-ract interface 0 = ( 
public 

isAfter, isEefore: abstract op 
(object: protected Ordered) 
Boolean; 

max, min: op (object: Ordered) 
Ordered; 

) ; 

Package: interface (Const rainedSet [Class], 
Cited, Interchanged) = ( 
publ ic 

constraint : sealed; 
system 

initialize: unprotected op ( 
title : Identifier ! ; 
ma jorEdit ion, minorEdit ion : 
Integer ; 

items : Class . . . ) 
throws IcemDuplicated, 
FrocessNot Peer ; 
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Pattern: interface (Object, Ordered) = ( 
publ ic 

find: op (string: protected 

String]; position: Integer | Ni 
List [Integer] j Nil 

throws Positionlnvaiid; 
substitute: op ( 

repetitions : Integer; 

string: unprotected String!; 

replacement: protected String!) 

Integer; 

system 

initialize: unprotected cp (text: 

copied String ! ) 
throws Patternlnvalid; 

) ; 



Permit : 



interface (Object, Ordered) = { 
public 

age, authenticity, charges, 

extent, priority: Integer | Nil ; 



canCharge, canCreate, canDeny, 
canGo, canGrant , canRestart, 
canSend : Boolean ; 

intersect : op (permit : Permit) 
Permit ; 

system 

initialize: unprotected op (age, 
charges, extent: Integer J Nil ) ; 



Petition : interface 
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public 

agent Class : Citation j Nil ; 

agentNarae : Telename ] Nil ; 

maximumWait : Integer | Nil ; 
system 

initialize: unprotected cp ( 
agentName : Telename | Nil ; 
agentClass : Citation | Nil ; 
maximumWait: Integer | Nil) ; 

) ; 

abstract interface 0 ~ ( 
system 

meeting: unprotected op ( . 

contact: Contact; petition: 
protected Petition) 
throws Meet ingDenied ; 

parting: unprotected cp (contact: 
Contact ) ; 

) ; 

abstract interface (Process, Unmoved; = 
public 

address: sealed readonly protected 
Teleaddress; 

publicClasses : sealed readonly Set 
[Cited] ; 

terminate: sealed unprotected op ( 
occupant: protected Telename) 
Boolean 
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) ; 



throws ProcessNotCurrent , 

FrocessNocPeer , St ace Improper 

system 

entering: unprotected op ( 

contact: Contact; 

permit: protected Permit; 

ticket: protected Ticket [Nil] 
throws OccupancyDenied; 

exiting: unprotected op ( 
contact: Contact; 
permit: protected Permits- 
ticket: protected Ticket jNil) 



Primitive: abstract interface (Object, Executed, 
Unchanged) = ( 
system 

initialize: unprotected op () 
throws FeatureUnavailable ; 

) ; 



Primitive abstract interface 
rogranmingException) = () ; 
Exception : 

DivisionByZero: interface 

(PrimitiveException) = (); 



Procedure: sealed interface (Primitive) = ( ) ; 

Process: abstract interface (Object, Named, 
Unccpied) = ( 
public 

brand: sealed readonly protected 
Object 

throws ProcessNc tPeer ; 
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localPermit: sealed copied Permit 
throws FeatureUnavailable , 
Permit Viol a ted; 

nativePermit : sealed copied Permit 
throws FeatureUnavailable , 
PermitViolated; 

permit : sealed readonly copied 

throws ProcessNot Peer ; 

regionaiPermit : sealed copied 

throws FeatureUnavailable , 
PermitViolated ; 

private 

age: sealed readonly Integer; 
charges: sealed readonly Integer; 
contacts: sealed readonly 

priority: sealed IntegerjNil; 

privateClasses : sealed readonly 
Set [Cited] ; 

publ ic 

charge: sealed op (charges: 

Integer) 
throws Permit Inadequate , 

PermitViolated; 
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restricc_x: sealed op ( 
procedure : Procedure ; 
permit: protected Permit) 

throws Exception, Permit Violated, 
ProcessNotCurrent ; 

spor.sor_x: sealed op ( 
procedure : Procedure ; 
permit: protected Permit) 

throws Exception, PermitViolated, 
ProcessNotCurrent ; 

wait: unprotected op (seconds: 
Integer) ; 

system 

initialize: cp f 

nativePermit : copied Permit; 
privateClasses : Set 
[Cited] [Nil) 
throws PermitViolated; 

live: abstract unprotected op 

(cause : Exception j Nil ) 
throws Exceptions- 
restricted: op (permit: 

Identifier; isRelocated: 
Boolean) PermitReduced j Ni 1 ; 

> ; 

Process- abstract interface 

(ProgrammingException) = (); 

Exception : 

Permitlnadequace : interface 
(ProcessException) = () ; 
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Condit ionUnavailable : 

interface ( ProcessExcept ion) = (); 

Condit ionUndef ined : 

interface (ProcessException) = (); 

5 PermitExhausted : 

interface (ProcessException) = {); 

PermitViolated : 

interface (ProcessException) = (); 

ProcessNotCurrent : 
10 interface (ProcessException) = (J; 

ProcessNotPeer : 

interface (ProcessException) = (); 



RescurceUnavailable : 
30 interface (ProcessException) = (); 

-5 Statelmproper : 

interface (ProcessException) = () 



50 25 



Programming abstract interface (Exception) = () 
Exception : 

Qualified sealed interface (Identifier) = (); 
20 Identifier: 



RandomStreaxt: interface (Scream [Integer]) = ( 

system 

initialize: unprotected op (seed: 

Integer) 
throws Seedlnval id ; 

) ; 
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sealed interface (Number) = (); 

abstract interface ( ) = ( 
publ ic 

discard: sealed op (); 

isProtected: sealed readonly 
Boolean ; 

isSa:ne: sealed op (reference: 

protected Referenced) .Boolean; 

protect: sealed op () protected 
Referenced; 

ref_x: sealed unprotected op (]; 

) ; 

interface = ( 
public 

condition : Identifier I 
throws ConditionUnavailabie; 

conditions: readonly protected Set 
[Identifier ! ] ; 

use: sealed unprotected op ( 
procedure : Procedure ; 
exclusive : Boolean | Nil ; 
maximumWait : Integer J Nil ; 
conditions: copied Set 
[Identifier!] [Nil) Boolean 

t hrows Condi c ionUnde f ined , 

Exception, ResourceUnavai labie ; 

system 
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initialize: unprotected op ( 
condition: Identifier! [Nil; 
conditions: copied Set 

[Identifier!] ,'NiI) throws 
Condit ionUndef ined; 

) ; 

Selector: sealed interface (Primitive) = () ; 

Set: interface [itemClass: Class] 

(Collection [itemClass] , Verified) = 

( 

public 

difference, intersection, union: 
unprotected op (set: protected Set 
[itemClass] ) ; 

system 

initialize: unprotected op (items: 

itemClass . . . ) 
throws ItemDuplicated, I temlnval id; 

) ; 

Stack: interface [itemClass: Class] (List 
[itemClass] ) = ( 
public 

pop: unprotected cp () itemClass 
throws StackDepleted; 

push: unprotected op (item: 
itemClass) ; 

pushltems: unprotected op { 
items: protected List 
[itemClass] ) ; 
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roll: unprotected op {shifts, 

items: Integer) 
throws Argument Invalid, 
StackDepleted; 

10 5 swap: unprotected op {) 

throws StackDepleted; 
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Stream: abstract interface [itemClass: Class] 

t 

1° public 

current: abstract readonly 
itemClass j Nil ; 

isDcne: abstract Boolean; 

next : abstract readonly 
15 itemClass | Nil 

throws Ref erenceFrotected ; 



String: sealed interface 

(ConstrainedList [Character] , Cased, 
^° Executed) = { 

publ ic 

constraint : sealed; 
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substring: op ( initial Pos it ion , 
beyondFinalPosition : Integer) 
copied String 

throws Positionlnvalid; 
system 

initialize: unprotected op 
(segments: Object ... 
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/* Character ( protected St 
*/) ; 



Teleaddress : 



interface = ( 
public 

location: String! j Nil ; 



provider : CctetString ! ; 

routingAdvice : List 
[OctetString ! ] ; 
system 

initialize: unprotected op ( 
provider : OctetString ! j Nil ; 
location: String! [Nil) ; 



Telename: interface = { 
pubi ic 

authority: OctetString! ; 

identity: OctetString! [Nil; 
system 

initialize: unprotected op ( 
authority, identity : 
OctetString; !Nil) ; 

) ; 

Telenumber: interface = ( 
public 

country, telephone: String!; 



extension : String ! j Nil ; 
system 
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initialize: unprotected op ( 
countryAndTelephcne : String I ; 
extension: String! jNii) ; 

) ; 

Ticket: interface (TicketStub) = ( 
public 

desiredWait , maximumWait : 
Integer j Nil; 

destinationAddress : 
Teleaddress | Nil ; 

destinaticnClass : Ci tat ion \ Nil ; 

destinationName : Telename 'Nil ; 

destinationPermit : Permit jNil; 
system 

initialize: unprotected op { 

destinationName : Telename | Nil ; 
destinationAddress : 
Teleaddress |Nil; 
destinaticnClass : Citation J Nil ; 
maximunWait : Inceger [Nil / 
way: Way jNil; 
travelNotes: Object jNil) ; 

) ; 

ketStub: interface = { 
publ ic 

travelNotes : Obj ect | Nil ; 

way: Way | Nil ; 
system 

initialize: unprotected op ( 
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way: Way j Nil; 
travelNotes: Object! Nil) ; 

) ; 

Time: interface (Object, Ordered, Unchanged) = 

( 

public 

adjust: op (seconds: Integer) Time; 
interval: op (subtrahend: Time) Integer; 
\ . 

pException: abstract interface (Exception) = { 
public 

ticketStub: sealed TicketStub; 
system 

initialize: unprotected op 
(ticketStub: TicketStub) ; 

) ; 

Dest inationUnavailable : 

interface (TripException) = {}; 

Dest inationUnknown : 

interface (TripException) = (); 

OccupancyDenied : 

interface (TripException) = (); 

TicketExpired: interface (TripException) 
= O ; 

WayUnavailable : interface 
(TripException) = 0 ; 

Unchanged: abstract interface () = (); 
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Unexpected: interface (Execut ionExcept ion) = ( 
Exception: public 

exception: readonly Exception; 
system 

5 initialize: unprotected op ( 

exception: Exception) ; 

) ; 



Unmoved: abstract interface () = (); 

Verified: abstract interface () = ( 
0 public 

verify: abstract op () Boolean,- 

) ; 



Way: interface = ( 
public 

authenticator : Authent icator j Nil ; 
means: Means | Nil; 



name : Telename j Nil ; 
system 

initialize: unprotected op ( 
name : Telename |Nil ; 
means : Means j Nil ; 
authenticator: 
Authent icator j Nil } ; 

) ; 

) /* Telescript */ 



8 PREDEFINED CLASS GRAPH 

The diagram below shows the part of the class graph 
involving the predefined classes. The immediate 
subclasses of a class lie indented just below it. Classes 
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which are underlined are abstract. Parentheses ( " ( M and 
"J") enclose mix-ins. 
Object ( Referenced ) 

Association ( Ordered ) 
Authent icator 
Calendar Time 
Citation ( Ordered ) 
Class ( Cited & Interchanged ) 
Class Definition 
Col lect ion 

List ( Ordered ) 

• Constrained List ( Constrained ) 

• • Bit String ( Executed ) 

• • Octet String ( Executed ) 

• • String ( Cased & Executed ) 

• Stack 
Set ( Verified ) 

• Constrained Set ( Constrained ) 

• • Package ( Cited & Interchanged ) 

• Dictionary 

• • Constrained Dictionary ( Constrained ) 

• • • Lexicon 
Constraint 
Contact 

Exception (Unchanged) 
Meeting Exception 
Programming Exception 

• Class Exception 

• Collection Exception 

• Kernel Exception 

• • Execution Exception 

• • • Unexpected Exception 

• Miscellaneous Exception 

• Primitive Exception 

• Process Exception 
Trip Except ion 
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Feature 

• Attribute 

• Operation 
Implementation 
Interface 
Means 

Method 

Pattern ( Ordered ) 
Permit ( Ordered ) 
Petition 

Primitive ( Executed & Unchanged ) 
Bit ( Ordered ) 
Boolean ( Ordered ) 
Character ( Cased & Ordered ) 
Identifier ( Ordered ) 

• Qualified Identifier 
Mark 

Modifier 
Nil 

Number ( Ordered ) 

• Integer 

• Real 
Octet ( Ordered ) 
Procedure 
Selector 

rocess ( Named ) 



Agent 

Place ( Unmoved ) 
• Meeting Place 
Resource 
Stream 

• Random Stream 
Teleaddress 
Telename 
Telenumber 
Ticket Stub 
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• • Ticket 

• Time ( Ordered & Unchanged ) 

• Way 

Cased 
5 Cited 

Constrained 

Contacted 

Executed 

Hashed 
0 Named 

Ordered 

Petitioned 

Referenced 

Unchanged 
5 • Interchanged 

Unmoved 

Verified 
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APPENDIX B 

Copyright @ General Magic, Inc. 1991, 1992, 1993. All 
Rights Reserved 

The following Table of Contents is to assist the 
5 reader in understanding the organization of and locating 
information within this appendix. 
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4.3.5 Dictionary 

4.3.6 List 

4.3.7 Pattern 

5 4.3.8 Procedure Frame 

5 4.3.9 Random Stream 

4.3.10 Repeat Frame 

w 4.3.11 Restrict Frame 

4.3.12 Send Frame 

4.3.13 Stack 
10 4.3.14 Time 

15 

4.3.15 Use Frame 

4.3.16 User-defined Frame 

4.3.17 While Frame 

20 5 ENCODING PALETTES 

15 5.1 Conventions 

5.2 Language Classes 

5.2.1 Agent 

5.2.2 Association 

5.2.3 Attribute 
20 5.2.4 Calendar Tine 

5.2.5 Citation 

5.2.6 Class 

5.2.7 Class Definition 

5.2.8 Collection 
25 5.2.9 Constrained Dictionary 

5.2.10 Constrained List 

5.2.11 Constrained Set 

5.2.12 Constraint 
5 .2 . 13 Contact 

30 5.2.14 Dictionary 

45 5.2.15 Implementation 
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5.2.21 Operation 

5.2.22 Package 

5.2.23 Pattern 

5.2.24 Permit 

5 5.2.25 Petition 

5.2.26 Random Stream 

5.2.27 Resource 

5.2.28 Set 

5.2.29 Stack 

0 5.2.30 Teleaddress 

5.2.31 Telename 

5.2.32 Telenumber 

5.2.33 Ticket 

5.2.34 Ticket Stub 
5 5.2.35 Time 

5.2.36 Trip Exception 

5.2.37 Unexpected Exception 

5.2.38 Way 

5.3 Encoding Classes 

0 5.3.1 Catch Frame 

5.3.2 Collection Stream 

5.3.3 Predefined Frame 

5.3.4 Repeat Frame 

5.3.5 Restrict Frame 
5 5.3.6 Send Frame 

5.3.7 Use Frame 

5.3.8 User-defined Frame 

5.3.9 While Frame 



INTRODUCTION 

Section 1 of Appendix A of this disclosure introduc 
the major elements of the present invention and that 
discussion is incorporated herein by reference. The 
conventions described in Section 1.4.3 of Appendix A are 
followed in this appendix as well. 
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1 . 1 Organization 

This appendix is divided into three sections. 
Section 1 is this introduction. Section 2 introduces the 
Encoding Rules' major concepts. Section 3 defines the 
5 predefined classes and attributes -- beyond those in the 
Instruction Set -- that are used in encoding. 

1 . 2 References 

This appendix relies upon these other documents: 
[10646] 

0 Information technology Universal Coded Character 

Set (UCS) , ISO/IEC DIS 10646, International Organization 
for Standardization and International Electrotechnical 
Commission, 1990. 

[Telescript] 
5 Appendix A of this disclosure. 

[Unicode] 

The Unicode Sta ndard: Worldwide Character Encoding . 
Volume 1, Version 1.0, The Unicode Consortium, 
Addison -Wesley, 1991 . 

0 2 ENCODING CONCEPTS 

Teleparcels are conceived :> this section of this 
appendix. Subsections are devoted to teleparcels and to 
object, attribute, and reference encodings. 

2 . 1 Teleoarcel 
5 A M teleparcel" encodes an object, which is the 

teleparcel's "subject", the subject's components, and ail 
of their components, recursively. The class of the 
subject or any component can be either predefined or 
user-defined. 

0 Note: A teleparcel is a Telescript object in its 

canonical form. 



392 



EP 0 634 719 A2 



10 



15 



20 



25 



30 



35 



40 



45 



50 



Note : A teleparcel is the means by which an object is 

transported between two Engines. A source 
Engine transforms an object into a teleparcel 
and transports it to a destination Engine. The 
latter transforms the teleparcel into an object, 
thereby producing at the destination the same 
object consumed at the source. 

Note: A teleparcel 's subject is typically, although 

not exclusively, an agent. In such cases, the 
teleparcel encompasses the agent and all the 
objects the agent owns, including those that 
make up che agent's current execution state. 

2 . 2 Object Encoding 

An "object encoding" encodes an object and a 
reference to the object. 

2.2.1 Forms 

An object encoding assumes one of these forms: 

Executed 

An "executed object encoding" encodes an executed 
ob j ec: . 

Predefined 

A "predefined object encoding" encodes an unexecuted 
object whose class is predefined. 

user-defined 

A "user-defined object encoding" encodes an object 
whose class is user-defined. 

Protected 

A "protected object encoding" encodes an arbitrary 
object . 
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Encoding an object also encodes a reference to the 
object. The reference is protected iff either the object 
is uncnanged or the object encoding's form is protected. 

2- , 2 . 2 Rules 
5 The form of the object encoding for an object, and a 

reference, shall be selected in accordance with the 
following ru ies ( applied in the order given: 

1. A protected object encoding shall be selected if the 
reference is protected and the object is not 

^0 unchanged. 

2. An executed object encoding shall be selected if the 
object is executed. 

3- A predefined object encoding shall be selected if the 
class, of the object is predefined 
13 4. a user-defined object encoding shall be selected 
votherwise) . 

2 • 2 ■ 3, ?alett«»s 

_ An object encoding can draw upon an "encoding 
paiette", which is a set of predefined attributes and 
20 rules governing their inclusion in an object encoding 

A predefined or user-defined object encoding draws 
upon a -primary palette determined by the predefined 
class of which the encoded object, . 0 », is an example. An 
object is an "example" of a predefined class iff the 
■5 object is an implementation member of that class but of no 
predermed subclass thereof. 

A user-defined object encoding also draws upon a 
secondary P alette, which iS defined in section 5.2. 20 of' 
.hi, appendix, iff . 0 - is cUed , constrained( Qr ^ 
whi.e an instance of the predefined class of which "0.- is 
an example is not cited, constrained, or named. 

either"" in * P * leCte is designated 

e Ch r mandatory or optional, a -mandatory., attribute 
shall be represented in an encoding that draws ucon -he 
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palette, while an "optional" attribute may, but need not, 
be represented. A number is assigned, for encoding 
purposes, to each optional attribute. 
Note: No object is an example of a mix-in. 

5 2.2.4 Encoding Classes 

The encoding palettes admit encoding classes as 
described in Section 4.2 of this appendix. An "encoding 
class" is a predefined class -- beyond the "language 
classes" which are classes described in Appendix A of this 
0 disclosure -- that supports the Instruction Set for 

encoding purposes but is not part of the Instruction Set. 
Note: An encoding class' only purpose is to define 

encoding attributes. Such a class has no 
initialization parameters, operations, 
5 adaptations, or conversions. 

2.2.5 Encoding Attributes 

The encoding palettes admit encoding attributes as 

described in Section 4.3 of this appendix. An "encoding 

attribute" is a predefined attribute -- beyond the 
0 "language attributes" which are described in Appendix A of 

this disclosure that supports the Instruction Set for 

encoding purposes but is not part of the Instruction Set. 

Every encoding attribute is a system instance attribute. 

Note: An encoding attribute does not preclude the 

5 interface of a user-defined class from providing 

an attribute with the same identifier. 

2 . 3 Attribute Encoding 

An "attribute encoding** encodes a predefined 
attribute and a reference to the attribute. 

0 2.3.1 Forms 

An attribute encoding assumes one of these forms: 
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Boolean 

A "boolean attribute encoding" encodes an instance 
class "Boolean" . 

Dial String 

5 A "dial string attribute encoding" encodes an 

instance of class "Dial String". 

Integer 

An "integer attribute encoding" encodes an instance 
of class "Integer". 

0 I tern 

An "item attribute encoding" encodes an object or a 
reference to the object. 

List 

A "list attribute encoding" encodes an instance of 
5 class "List " . 

Octet Strinc 

An "octet string attribute encoding" encodes an 
instance of class "Octet String" . 

Stack 

0 A "stack attribute encoding" encodes an instance of 

class "Stack" . 

String 

A "string attribute encoding" encodes an instance of 
class "String". 

5 2.3.2 Rules 

The form of the attribute encoding for an attribute 
shall be selected in accordance with the following rules, 
applied in the order given: 
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1. An attribute encoding other than an item attribute 
encoding shall be selected if the attribute is an 
instance of the required class. 

2. An item attribute encoding shall be selected 
(otherwise) . 



2 . 4 Reference Hncodina 

A "reference encoding" encodes a reference to an 
object that is encoded by an object encoding. 



2.4.1 Forms 

A reference encoding assumes one of these forms: 



General 

A "general reference encoding" encodes a (protected 
or unprotected) reference that denotes an object by means 
of the "offset" in octets from the start of the reference 
encoding to the start of the object encoding. The offset 
is positive or negative if the object's encoding follows 
or precedes the reference's, respectively. Offsets shall 
be negative; positive offsets are reserved. 

Voided 

A "voided reference encoding" encodes a reference 
that is voided. 



Interchange 

An "interchange reference encoding" encodes a 
reference that denotes an interchanged object by means of 
both the object's digest and a citation co the class of 
which the object is an instance. 

Class 

A "class reference encoding" encodes a reference that 
denotes a class by means of either the class' numeric 
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code, if the class is predefined, or a citation to the 
class, if the class is user-defined. 

Procedure 

A "procedure reference encoding" encodes a reference 
to a procedure that is in the implementation of a 
user-defined class. A procedure reference encoding shall 
be used to encode only the "procedure" attribute of a 
predefined frame, F. A procedure reference encoding 
expresses, by means of an integer, the procedure's 
position in the "procedure" attribute of the procedure 
frame, " B " , just below " F " in the "frames" attribute of 
which "F" is an item. The integer is either the position 
itself, if the integer is greater than or equal to one, or 
one plus the arithmetic difference between the position, 
the minuend, and the "position" attribute of F, the 
subtrahend, otherwise . 

2.4.2 Rules 

The form of the reference encoding of a reference to 
an object shall be selected in accordance with the 
following rules, applied in the order given: 

1. A voided reference encoding shall be selected if the 
reference has been voided. 

2. A class reference encoding shall be selected if the 
object is a predefined class. 

3. A general reference encoding shall be selected if the 
object is encoded as part of the teleparcel, rather 
than presumed present at the teleparcel' s 
destination . 

4. A class or procedure reference encoding shall be 
selected if the object is a user-defined class or a 
procedure in a user-defined class implementation, 
respectively . 

5. An interchange reference encoding shall be selected 
(otherwise) . 
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Not-: Thus Rule 3 applies iff the object is encoded 

part of the teleparcei, rather than presumed 
present at the teleparcei' s destination. 

2 ENCODING SP5CTFTCATI0NS 

5 Teleparceis are defined in this section of this 

appendix. Subsections are devoted to teleparceis and to 
object, attribute, and reference encodings. 

3 . 1 Convent ions 

A teleparcei is a series of tokens, each of which i 
0 zero or more octets. The teleparcei is the octet string 
obtained by concatenating the tokens. 

A teleparcei obeys the syntactic, and accompanying 
semantic, rules below. Given in 3NF (Backus-Naur or 
Backus normal form), the rules surround optional tokens 
5 brackets ( " [ " and "J"). 

Table B.l assigns codes to the forms of object and 
reference encoding. These codes are used as tags in the 
sections below. 





TA3LE B.l 


-50 


ProcedureRef erence 


-51 


InterchangeRef erence 


-52 


UnprotectedRef erence 


-53 


Predef inedClassRef erence 


-54 


PrctectedReferer.ee 


-55 


ProtectedCb ject 


-56 




-57 




-58 


UserDef InedClassRef erence 


-5 9. 


VoidedRef erence 


-60 


Mixins 
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Note: The sections below follow the conventions of 

Sections 5.1 and 5.3 of Appendix A of this 
disclosure . 

3 . 2 Teleparcel 
5 A teleparcel obeys this rule: 

Teleparcel ::= unsignedNumber unsignedNumber Object 

The first and second "unsignedNumber" encode the 
number of the major and minor versions of the Encoding 
Rules to which the teleparcel conforms, respectively. 
0 "Object" encodes the teleparcel 's subject and the 
subject's components. 

Note: The numbers of the major and minor versions, of 

the Encoding Rules that this appendix defines 
are 0 and 5, respectively. 

5 3 . 3 Object Encoding 

An objects encoding obeys this rule, which reflects 
the defined forms: 

Object ExecutedObject | Predef inedCb j ect 

| UserDef inedObject j ProtectedObject 

0 3.3.1 Executed Object 

An executed object encoding obeys the rule set out i 
Sectins 5.1 and 5.3 of Appendix A of this disclosure. 

The tag that is the first token in "ExecutedObject" 
identifies the object as executed and reveals the object' 
5 class by encoding twice the class' code. 

Note: An executed object is encoded as in a binary 

teiescript . 

3-3.2 Predefined Object 

A predefined object encoding obeys this rule: 
0 Predef inedObject ::= tag Palette 
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The tag identifies the object as predefined and 
reveals the object's class by encoding twice the class' 
code. The "Palette" draws upon the primary encoding 
palette for the class of which the object is an example. 

3.3.3 User-defined Object 

A user-defined object encoding obeys this rule: 
UserDef inedCbject ::= [Palette Mixins] tag Item Item 
Palette Mixins : ; = tag 

The first "tag" identifies the object as user-defined 
and reveals the class of which the object is an example by 
encoding one plus twice the class' code. 

The first "Item" encodes the object's class, the 
second a list whose items correspond to the user-defined 
implementation superclasses of that class in their 
canonical order. Each item is itself a list, a list of 
the properties of the instance native to the class to 
which the item corresponds, in the order of their 
identifiers in the "properties" attribute cf the class' 
implementation. The final one or mere properties can be 
omitted, in which case nils are implied. 

The first "Palette" draws upon the secondary encoding 
palette and is present iff "Mixins" is present. The 
second "Palette" draws upon the primary palette for the 
class of which the object is an example. 

3.3.4 Protected Object 

A protected object encoding obeys these rules: 
ProtectedObject ::= tag ProtectedOb j ect Itself 

ProtectedObjectltself ::= ExecutedOb j ect j 

Predef inedObj ect | 
UserDef inedObj ect 
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The "tag" identifies the reference as protected. The 
"ExecutedObject", the "Predef inedObject " , or the 
"UserDef inedObject" encodes the object . 

3.3.5 Palette 

An encoding palette's encoding obeys these rules: 

Attributes [Mask Attributes] 
uns ignedNumber 
(Attribute Attributes] 



Palette 
Mask 
Attributes 



The first "Attributes" encodes the zero or more 
10 attributes that the palette declares mandatory, in the 
order in which they are listed in the table that defines 
the palette. The table fixes the number of occurrences of 
"Attribute" . 

The "Mask" and the second "Attributes" are present 
25 15 iff the palette declares any attributes optional. The 

second "Attributes" encodes zero or more of the optional 
attributes. The "Mask" fixes the number of occurrences of 
"Attribute" . 

30 

The "Mask" encodes an integer indicating which 
20 optional attributes the second "Attributes" encodes. The 
palette's table numbers the optional attributes in the 

35 range of [1, n ] . The second "Attributes" includes an 

encoding of the attribute numbered »i« iff the bit in the 
integer's representation weighted 2" 1 is one. The 

^ 25 attributes actually encoded appear in the second 

"Attributes" in order of increasing "i". Bits logically 
required by "n" but physically absent from "Mask" shall be 
considered zero. Bits physically present but logically 

45 not required shall be ignored. 



30 3_^-i Attribute Encoding 

An attribute encoding obeys this rule, which reflects 
the defined forms: 
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Attribute 

Integer J 

String 

5 3.4.1 Boolean 

A boolean attribute encoding obeys this rule: 
Boolean : : = empty 

The boolean attribute encoding is present iff the 
boolean is "true". 
10 Mote : The encoding's presence is indicated by the mask 

that encompasses the encoding. 
Note: Thus a palette's boolean attributes are 

necessarily optional. 

3.4.2 Dial String 

!5 A dial string attribute encoding obeys this rule: 

DialString ::= OctetString 

The "OctetString" encodes the octet string, "0", 
determined by the list, "L" , of nibbles determined in turn 
by the dial string, " D 11 , and having the same length. 
20 A nibble of "L" encodes unsigned the integer in the 

range [0, 14] determined by the character of "D" at the 
same position. The numerals ("0 M - M 9") determine 0-9, a 
dash (»-») determines 13, and a space (" ") determines 14. 
The nibble of "L" at position 2i-l or 2i, "i". being at 
25 least one, occupies Bits 7-4 or 3-0, respectively, of the 
octet of "0" at position » i . Bit 7 or 3 , respectively, 
is the MSB, Bit 4 or 0, respectively, the LSB . Iff the 
length of "D" and thus is odd, Bits 3-0 of the last 

octet of "0 M encode 15 in the same way. 

Thus a dial string is encoded in a form of 
Binary Coded Decimal (BCD) . 



3coiean J DialString j 
Item : List | OctetString j 
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3.4.3 Integer 

An integer attribute encoding obeys this rule: 
Integer : : - signedNumber 

The " signedNumber " encodes the integer. 
5 Ncte : This is a binary telescript encoding of an 

integer, except that the initial token, 
identifying the encoding as an integer's general 
encoding, is absent. 

3.4.4 Item 

0 An item attribute encoding obeys this rule: 

Item ::= Object j Reference 

The "Object" or "Reference" encodes the object or a 
reference to the object, respectively. 

3.4.5 List 

5 A list attribute encoding obeys these rules: 

List ::= unsignedNumber Items 

Items [Item Items] 

The "unsignedNumber" and "Items" together encode the 
list. The former encodes the number of occurrences of 
0 "Item" in the latter, which in turn encode the items of 
the list in order of increasing position. 

3.4.6 Octet Strinc 

An octet string attribute encoding obeys this rule: 
OctetString ::= unsignedNumber Octets 

5 The "unsignedNumber" and "Octets" together encode the 

octet string as specified in Section 5.3.2 of Appencix A 
of this disclosure. 

Note: This is a binary telescript encoding of an octec 

string, except chat the initial token, 
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identifying the encoding as an octet string's, 
is absent . 

3.4.7 Stack 

A stack attribute encoding obeys the same rules as a 
list attribute encoding, except that the items of the 
stack are encoded in order of decreasing position. 

3.4.8 String 

A string attribute encoding obeys this rule: 

String ::= uns ignedNumber characters 

The "unsignedNumber " and "characters" together encode 
the string as specified in section 5.3.2 of Appendix A of 
this disclosure. 

Note : This is a binary telescript encoding of a 

string, except that the initial token, 
identifying the encoding as a string's, is 
absent . 

3 . 5 Reference Encoding 

A reference encoding obeys this rule, which reflects 
the defined forms: 

Reference : : = GeneralRef erence | 

VoidedRef erence \ 
InterchangeRef erence ] 
ClassRef erence j 
ProcedureRef erence 

3.5.1 General Reference 

A general reference encoding obeys these rules. One 
encoding is defined for unprotected references, another 
for protected references: 

GeneralRef erence UnprotectedRef erence \ 

ProtectedRef erence 
UnprotectedRef erence ::= tag signedNumber 
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ProcectedRef erence ::= tag signedNumber 

5 

The "tag" identifies the general reference as such 
and as either unprotected cr protected. The 
" s ignedNumber " encodes the offset from the reference 
10 encoding to the object encoding of the referenced objeci. 



3.5.2 Voided Reference 
A voided reference encoding obeys this rule: 

VoidedRef erence tag 

The "tag" identifies the voided reference as such. 

3.5.3 Interchange Reference 
An interchange reference encoding obeys this rule: 

InterchangeRef erence :: = tag Item Item 

The "tag" identifies the interchange reference as 
such. The first "Item" encodes a citation to the 
interchanged object's class. The second "Item" encodes 
the interchanged object's digest. 

3.5.4 Class Reference 

35 A class reference encoding obeys these rules. One 

encoding is defined for predefined classes, another for 
user-defined classes: 

ClassRef erence ::= Predef inedClassRef erence j 

40 

UserDef inedClassRef erence 
Predef inedClassRef erence ::= tag unsignedNumber 

UserDef inedClassRef erence ::= tag Item 

45 

The "tag" identifies the class reference as such and 
the class as either predefined or user-defined. If the 
class is predefined, the "unsignedNumber" encodes the code 
50 assigned to the class either in Section 5.4.1 of Appendix 

A of this disclosure or in Table 3.2, below, of this 



25 
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appendix. If the class is user-defined, the "Item" 
encodes the class' citation. 

3.5.5 Procedure Reference 

A procedure reference encoding obeys this rule: 
5 ProcedureRef erence ::= tag signedNumber 

The "tag" identifies the procedure reference as such. 
The "signedNumber" identifies the procedure's position as 
previously described. 

4 ENCODING CLASSES AND ATTRIBUTES 

0 Teiescript's encoding classes and attributes are 

defined in this section of this appendix. A subsection is 
devoted to first the encoding of classes and then the 
encoding of attributes. 

4 . 1 Conventions 
5 Encoding Classes 

The encoding classes form a group. The section below 
that defines this group fellows the conventions, e.g., of 
Section 3.2 of Appendix A of this disclosure. 

Table B.2 assigns identifier codes to the encoding 
C classes. 





TABLE B.2 


144 


CatchF rate 


145 


Col lectionS t ream 


146 




147 


Predef inedFrame 


143 


GoFrame 


149 


RepeatFrame 


150 


Restrict Frame 
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151 



SendFrame 



useFrame 



LS 3 



UserDe f inedFrame 



171 



WhileFrame 



5 Note: Classes " Frame" and "Procedure Frame" require no 

codes because rhey are abstract. Class "Dial 
String" requires no code because its instances 
have their own encodings. 
Note: Because an encoding class' only purpose is to 

0 define encoding attributes, this appendix does 

not devote a major section to each encoding 
class, even though Appendix A devotes such a 
section, e.g., Section 4 . 2 to every language 
class. 

5 Encoding Attributes 

The encoding attributes are native to certain 
language and encoding classes. The section below that 
defines the encoding attributes devotes a subsection to 
each predefined class to which such attributes are native. 

: The classes are considered in alphabetical order. An 
encoding attribute's definition follows the conventions 
established in Section 4.1 of Appendix A of this 
disclosure . 

Note.: Identifier codes need not be assigned to the 

> encoding attributes. 

4 • 2 Encoding Group 
Object (Referenced) 

• Collection 

• • List (Ordered) 

• • • Constrained List (Constrained) 
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• 



String (Cased & Executed) 
• Dial String 



rame 



Procedure Frame 

• Predefined Frame 



Catch Frame 
Repeat Frame 
Restrict Frame 
Use Frame 
While Frame 
User-defined Frame 



Go Frame 
• Send Frame 
Stream 

• Collection Stream 



25 4.2.1 Catch Frame 

Attributes 

exception 

A "catch frame" is a predefined frame whose subject 
30 20 method is the method for "catch" and whose "procedure" 
attribute is the operation's responder. 

A catch frame's native attribute is the class that is 
35 the operation's argument (attribute "exception"). 

4.2.2 Collection Stream 

2 5 At tribut es 
40 position 

source 

A "collection stream" is a stream whose items are 
those of a collection. 

45 

30 A collection stream's native attributes are the 

stream's source (attribute "source") and the stream's 
current position (attribute "position"). The "source" is 
so the collection whose items the collection stream produces. 

The "current position" is a position in the "items" 



55 
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attribute encoding the collection stream's source. The 
collection stream last produced the item at the stream's 
current position, previously produced any items at 
positions before the current position, and has yet to 
5 produce any items at positions after the current position. 
Note: A collection stream is the result of the 

"stream" operation when the latter is performed 

by a collection. 



4.2.3 Dial String 

A "dial string" is a string each item of which is 
either a numeral ( « 0 " - " 9 " ) , a hyphen ("-"), or a space (" 
") . 

Note: Dial strings are used in teienumbers. 



4.2.4 Frame 

A "frame" is an object recording the current state of 
a performance of a predefined or user-defined method, the 
frame's "subject method". 



4.2.5 Go Frame 

A "go frame" is a frame entailing the taking of a 
0 trip. The method is the predefined method for either 
operations "go" or "send", the former in the case of an 
instance of this class, the latter in the case of an 
instance of this class' subclass. 

4-2.6 Predefined Frame 

5 A "predefined frame" is a procedure frame whose 

subject method is predefined, and thus whose procedure is 
not that method. The subject method of an instance of 
this class is the method for operations "do", "either", 
"if" , "loop" , or "select" . 
3 Note : Which of the above operations applies is 

determined by examining the identifier by means 
of whose execution the operation was requested. 
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4.2.7 Procedure Frame 
Attributes 

position 
crocedure 

5 A "procedure frame" is a frame entailing a 

procedure's performance. 

A procedure frame's native attributes are the 

procedure being performed (attribute "procedure") and the 

procedure's current position (attribute "position"). A 
0 procedure's "current position" is chat of the item the 

Engine is currently executing. 

Note : The procedure is either the "procedure" 

attribute of the subject method, the responder 
of the feature the method implements, or an 
5 argument of the feature. 

4.2.8 Repeat Frame 
Attributes 

repeti t ions 
repetitionsSoFar 
0 A "repeat frame " is a predefined frame whose subject 

method is "he method for operations "repeat" and whose 
"procedure" attribute is that operation's responder. 

A repeat frame's native attributes are the number of 
performances of the frame's "procedure" attribute, 
5 including the current performance, that have been 

initialed (attribute "repetitionsSoFar"), and the number 
requested at the outset (attribute "repetitions"). 

4.2.9 Restrict Frame 
Attributes 

0 permit 

A "restrict frame" is a predefined frame whose 
subject method is the method for operations "restrict" and 
whose "procedure" attribute is that operation' s argument. 
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A restrict frame's native attribute is the permit the 
subject held at the start of the Engine's performance of 
the subject method (attribute "permit") . 

4.2.10 Send Frame 
5 Attributes 

tickets 

A "send frame 11 is a go frame whose subject method is 
the .predefined method for operations "send". 

A send frame's native attribute comprises one or more 
0 of the tickets originally in the operation's argument 
(attribute "tickets") . 

4.2.11 Use Frame 
Attributes 

resource 

5 A "use frame" is a predefined frame whose subject 

method is the method for operations "use" and whose 
"procedure" attribute is one of the operation's arguments. 

A use frame's native attribute is the operation's 
responder (attribute "resource") . 

0 4 . 2 . 12 User-defined Frame 
Attributes 

responder 

stack 

variables 

5 A "user-defined frame" is a procedure frame whose 

procedure is that of the frame's subject method. * The 
subject method is user iefined and is necessarily a value 
of an implementation's "instanceMethods" or " setMethods " 
attribute . 

3 A user-defined frame's native attributes are the 

method's responder (attribute "responder"), stack 
(attribute "stack"), and variables (attribute 
"variables"), the latter in the order of their identifiers 
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10 



in Che method's "variables" attribute. The responder is 
the agent of whose "frames" attribute the user-defined 
frame is an item. 

Note: Let "I", if any, be an it err. in the "procedure" 

5 attribute of the frame, "3", if any, below the 

user-defined frame in the agent's "frames" 
attribute . In oarticular, let m i m be the item 
whose position in the "procedure" attribute is 
the "position" attribute of "3". "I" is either 
10 ia) non-existent: the subject method is for 

operations "live"; (b) an identifier preceded by 
a "setAttribute" modifier: the subject method is 
a value in an implementation's "setMethods" 
attribute; (c) an identifier not so preceded: 
15 the subject method is a value in an 

implementation's " instanceMethods" attribute; or 
25 (d) an "escalate" selector: the subject method 

is as described in either (b) or (c) abcve . 



75 



20 



30 



35 



40 



45 



50 



4 .2.13 While Frame 
2 0 Attributes 

is Precondition 
precondition 

A "while frame" is a predefined frame whose subject 
method is the method for operations "while" and whose 

25 "procedure" attribute is that operation's responder. 

A while frame's native attributes reveal the executed 
object that is the operation's argument (attribute 
"precondition") and whether the argument, rather than the 
responder, is being performed (attribute 

30 "isPreccndition" ) . The while frame's "position" attribute 
pertains to whichever of the two procedures is being 
performed . 

4 . 3 Encoding Attributes 

The encoding attributes are defined below. 
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4.3.1 Agent 

Native to this class are the following encoding 
attributes. 

frames : 

sealed Stack [Frame] !; 

The responder's pending frames. The bottom frame's 
subject method is a user-defined method for operations 
"live". The top frame's subject method is the built-in 
method for operations "go" or "send". There are zero or 
more other frames. 

nat ivePermit : 

sealed copied Permit | Nil; 

Either the responder's native permit, if it differs 
from the permit the responder holds, or a nil, otherwise. 

5 4-3-2 Catch Frame 

Native to this class is the following encoding 
attribute . 

exception : 
sealed Class; 

C "The class either class "Exception" or 

thereof -- that is performing the • responder ' s 
method, 

4.3.3 Collection 

Native to this class is the following encoding 
5 attribute. 

items : 

sealed List [Ob j ect ] i ,- 



a subclass 
sub j ect 
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The responder's items. The position of any 
particular item is undefined. 

4.3,4 Collection Stream 

Native to this class are the following encoding 
5 attributes . 

position : 

sealed Integer j Nil ; 

Either the current position in 
responder has produced neither none 
0 or a nil, otherwise. 

source : 

sealed Collection [Obj ect] j Nil ; 

Either the responder's source, if the responder has 
not produced all of its items, or a nil, otherwise. 

5 4.3.5 Dictionary 

Native to this class is the following encoding 
attribute . 

associations : 
sealed List [Object] »; 

The keys and values that form the responder's items. 
The items at positions 2i-l and 2i of the list are a key 
and its associated value, respectively. The position of 
any particular key- value pair is undefined. 

4.3.6 List 

Native to this class is the following encoding 
at tribute . 



the responder, if the 
nor all of its items, 
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items : 

sealed List [Object] !; 
The responder's items. 

4.3.7 Pattern 

5 Native to this class is the following encoding 

attribute . 

text : 

sealed copied String; 
The responder's text. 

10 4.3.8 Procedure Frame 

Native to this class are the following encoding 
attributes . 

position : 

sealed Integer; 

15 The current position in -he responder's "procedu 

attribute . 

procedure : 
sealed Procedure; 

The procedure whose performance the responder 
0 entails. 

4 • 3 . g Random Stream 

Native to this class is the following encoding 
attribute. 

seed : 

5 sealed Integer; 
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Either the responded s seed, if the responder has not 
produced an item, or the item the responder produced last, 

otherwise . 

4.3,10 Repeat: Frame 

Native tc this class are the following encoding 

attributes . 

yp pQt.it ions : 
sealed Integer; 

The number of performances cf the responder' s 
-procedure" attribute requested of the responder' s subject 
method via the argument of operations "repeat". 

rpyjetitionsSoFar : 
sealed Integer; 

The number of performances of the responder' s 
"procedure" attribute, including the current performance, 
initiated so far. 

4.3.11 Restrict Frame 

Native to this class is the following encoding 

attribute . 

permit : 

sealed copied Permit; 

The permit the subject held at the start of the 
oerformance of the responder ' s subject method. 



4.3.12. Send Frame 

Native to this class is the following encoding 

attribute . 
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tickets : 

sealed List [Ticket] !; 

One or more of the tickets in the list supplied as 
the argument of the responder's subject method. The 
5 position of any particular ticket is undefined. 

4.3.13 Stack 

Native to this class is the following encoding 
attribute . 



items : 

0 sealed Stack [Obj ect] !; 



The responder's items. 

4.3.14 Time 

Native to this class are the following encoding 
attributes . 

5 dst : 

sealed Integer; 

The ::st" attribute of the calendar time that would 
have been produced, when and where the responder was 
produced, by requesting "new" of class "Time" and 
0 converting its result to a calendar time. 



second : 

sealed Integer; 

The "second" attribute of the unnormal ized calendar 
time that denotes the same absolute point in time, "T", a 
5 does the responder, but that would denote time "T 0 " if it 
"second" attribute alone were set to zero. 
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Note : T 0 is the time relative to which all times are 

measured. It coincides with the start of a 
minute in the Gregorian calendar. This 
attribute, then, is the number of seconds that 
5 separate T from T 0 . The attribute is strictly 

positive or negative if the time follows or 
precedes T 0 , respectively. 

zone : 

sealed Integer; 

0 The "zone" attribute of the calendar time that would 

have been produced, when and where the responder was 
produced, by requesting "new" of class "Time" and 
converting its result to a calendar time. 

4.3.15 Use Frame 

5 Native to this class is the following encoding 

attribute . 

resource : 
sealed Resource; 

The resource performing the responder' s subject 
0 method. 

4.3.16 User -de fined Frame 

Native to this class are the following encoding 
attributes . 

responder : 
5 sealed Object; 

The responder of the responder' s subject method. 
stack : 
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sealed Stack [Object] ! ; 



The stack cf the responder's subject method. 



variables : 



sealed List [Object] ! ; 



5 



The variables cf the responder's subject method. 



4.3.17 



While Frame 



Native to this class are the following encoding 
attributes . 



isPrecondit icn : 



0 



sealed Boolean; 



Whether the responder's "precondition" attribute, 
rather than its "procedure" attribute, is being performed. 

precondition : 
sealed Executed; 



5 ENCODING PALLETTES 

Telescript's encoding palettes are defined in this 
section of the appendix. One section is devoted to 
language classes, another to encoding classes. All 

0 Engines of a network must agree on the following: (i) the 
method by which an assigned teleaddress' "provider" 
attribute is selected, and (ii) the method by which an 
assigned telename's "authority" attribute is selected. 
One embodiment of each of these methods is implemented in 

5 the computer software included as Microfiche Appendix G of 
this disclosure. 

5 . 1 Conventions 



5 



The argument of operations "repeat". 
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A subsection is devoted below to each predefined 
flavor whose examples are encoded using a non-empty 
primary palette. First the language flavors and then the 
encoding flavors are considered in alphabetical order. 
One additional subsection, entitled Mix-in, is devoted to 
the one secondary palette. 

Most every palette is defined using a table whose 
columns are labeled, and whose rows define predefined 
attributes, as follows. 

• £. Either "M", if che attribute is mandatory, 

or the number assigned to the attribute, if 
the attribute is optional. 

• Attribute . The attribute's identifier. 

• Sender . The attribute's type, defined using the 

notation of Section A. 2. 4 of Appendix A. 
If the type is "Boolean" and just one of 
its two instances is permitted, "true" or 
"false" appears in lieu of "Boolean". 

• Receiver . Either a dash ("-"), if a sending Engine 

shall net omit the attribute from an 
encoding, or the instance of the type that 
the receiving Engine shall supply if the 
sending Engine does emit the attribute, 
otherwise . 



5 . 2 Language Classes 

The encoding palettes for the language classes are 
defined below. 

Note : The absence from this section of certain 

language classes is explained as follows. An 
object's class and is Protected attributes 
figure in its encoding, but not as attributes. 
An object computes its size attribute. A place 
is immovable and thus not encoded. A process' 
class is not user-defined unless the process :s 
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10 



an agent or a place. A stream computes its 
"current", "isDone", and "next" attributes. 

5.2.1 Agent 

An example of this class is encoded using the primary 
oaiette in Table 3.3. 



15 



20 



25 



30 



35 



40 



10 



15 



TAHLE 3.3 


if 


Attribute 


Sender 


Receiver 


M 


name 


Telename 




M 


permit 


Permit 




M 


frames 


Stack [Frame] ! 




1 


brand 


Object 1 


Assigned 1 


2 


privateClasses 


Set [Cited] 


Cleared 


3 


nativePermit 


Permit 


Nil 


4 


priority 


Integer 


Permit 2 


5 


contacts 


Set [Contact] 


Absent 



45 



'This attribute shall be supplied by either the sending 
Engine, if the agent is transferred within a domain, or 
the receiving Engine, otherwise. 

"The "priority" attribute of the agent's "permit" 
20 attribute. 

5.2.2 Association 

An example of this class is encoded using the primary 
palette in Table 3.4. 



50 



TABLE B.4 


1 


Attribute 


Sender 


Rece i ver 
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M 


" key " 


Object 




M 


"value " 


Obj ecc 





5.2.3 Attribute 

An example of this class is encoded using the primary 
5 palette in Table B.5. 



TABLE B.5 


1 


Attribute 


Sender 


Receiver 




"exceptions" 


Set [Identifier ! ] 1 


Cleared 


2 


"isPublic" 


true 


false 


3 


"constraint" 


Constraint 


See Constraint 


4 


"isSet " 


true 


false 



*In a class, this is "Set [Class] " . Each class is class 
"Exception" or a subclass thereof. 

5.2.4 Calendar Time 

15 An example of this class is encoded using the primary 

paletce in Table B.6. 



TABLE B.6 


4 


Attribute 


Sender 


Receiver 


l 


"day" 


Integer 


Nil 


2 


"dayOfWeek" 


Integer 


Nil 


3 


M dayOfYear" 


Integer 


Nil 


4 


"est" 


Integer 


Nil 


5 


"hour" 


Integer 


Nil 
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TABLE 3 . 6 


6 


"minute " 


Integer 


Nil 


7 


"month " 


Integer 


Mil 


8 


" second" 


Integer 


Nil 


9 


" year" 


Integer 


Nil 


10 


" zone " 


Integer 


Nil 



5.2.5 Citation 

An example of this class is encoded using the primary 
palette in Table B.7. 





TABLE B.7 


£ 


Attribute 


Sender 


Receiver 


M 


"title" 


Identifier ! 




1 


"author" 


Telename 


Nil 


2 


"ma jorEditicn" 


Integer 


Nil 


3 


"minorEdir ion" 


Integer 


Nil 



5 5.2.6 Class 

An example of this class is encoded using the pri 
palette in Table B.3. 





TABLE B.8 


i 


Attribute 


Sender 


Receiver 


M 


"citation" 


Citation 




M 


" interface " 


Interface 
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TABLE 3.3 


1 


" i mp I err.e n t a t i on " 


Implementation 


Nil 


5.2.7 


Class Definition 







An example of this class is encoded using the primary 
palette in Table B.9. 



TABLE B . 9 


S 


Attribute 




Receiver 


M 


" interface " 


Interface 




M 


"title" 


Identifier ! 




1 


" implementation" 


Implementation 


Nil 1 


2 


"ma j orEdit ion" 


Integer 


1 


3 


"mi nor Ed it ion" 


Integer 


1 



5.2.9 Collection 

An example of this class is encoded using the primary 
palette in Table 3.10. 





7 A3 IE 9.10 




Attribute 


Sender 


Receiver 










1 


"items" 


Li • - [Object] ! 


Cleared 


5.2.9 


Constrained 


Diet ion a ry 





An example of this class is encoded using the primary 
palette in Table 3.11. 



425 



EP 0 634 719 A2 



5 



10 





TABLE 3.11 i 




Attribute 


Sender 




M 


"constraint " 


Constraint 


Receiver j 


M 


"associations" 


List [Object J 





5 5.2.10 Constrained List 

An example of this class is encoded using the primary 
palette in Table 3.12. 





TABLE 3.12 


4 


Attribute 


Sender 


Receiver 


M 


"constraint" 


Constraint 




M 


"items'* 


List [Object] 





5 • 2 . 11 Constrained Set 

An example of this class is encoded using the pri 
palette in Table B.13. 







TA3LE £ . 


£ 


Attribute 


Sender 


Receiver 


M 


"constraint" 


Constraint 




M 


"items" 


List [Object] 





5-2.12 Constraint 
20 An example of this class is encoded using the primar 

45 palette in Table B.14. 



] TABLE 3.14 

50 
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5 



10 



if 
n. 


Attribute 


Sender 


Rece iver 


1 


"is Instance" 


true 


false 


2 


M isOpticnai" 


true 


false 


3' 


"classic!" 


Identifier ! 


' Ob j ect 


3' 


"of Class" 


Class 


Obj ect 


4 


"passage " 


Identifier ! 


' byRe f 



'in a class, the "ciassld" and "ofClass" attributes are' 
present implicitly and explicitly, respectively, the 
former being the "title" attribute of the latter' s 

10 "citation" attribute. In a class definition and 

elsewhere, the "ciassld" and "of Class" attributes are 
present explicitly and implicitly, respectively, the 
latter being a nil. ' In either a class or class 
definition, the constraint is the "constraint" attribute 

15 of an attribute definition, the "result" attribute of an 
operation definition, or an item of the "arguments" 
attribute of an operation definition. In any of these 
cases, that feature definition is a value in the 
"classFeatures" or " ins tance? eatures " attribute of an 

20 interface. Finally, that interface is the "interface" 
attribute of the class cr class definition. 



5.2.13 Contact 

An example of this class is encoded using the primary 
palette in Table B.15. 



TABLE B.15 


1 


Attribute 


Sender 


Rece iver 








1 


"subject" 


Process 


Nil 


2 


"subjectClass" 


Citation 


Nil 



55 
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TABLE B . 15 


3 


" subj ectName " 


Telename 


Nil 


4 


"subjectNotes" 


Object 


Nil 


5.2.14 


Dictionary 







An example of this class is encoded using the primary 
5 palette in Table 3.16. 





TA3LE B . 16 


1 1 


Attribute 


Sender 


Receiver 


M 


"associations " 


List [Object] ! 





5.2.15 Implementation 

An example of this class is encoded using the primary 
palette in Table B.17. 





TABLE 3. 17 


I 


Attribute 


Sender 


Receiver 




"classMethods" 


Lexicon [Method] 


Cleared 


2 


" f romMethods" 


Lexicon [Method] 1 


Cleared 


3 


" ins tanceMet hods" 


Lexicon [Method] 


Cleared 


4 


"properties" 


List [ Ident i f ier : ] 


Cleared 


5 


"setMethods" 


Lexicon [Method] 


. Cleared 


6 


"superclasses" 


List (Identifier! ] : 


Nil 


7 


" toMethods" 


Lexicon [Method] 1 


Cleared 


8 


" vocabulary" 


Lexicon [Citation] 


Nil 



'In a class, this is "Dictionary [Class, Method]". 
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: In a class, this is " List [Class j " . 

5.2.16 Interface 

An example of this class is encoded using the primary 
palette in Table 3.13. 



TA3LE 3. 18 




Attribute 


Sender 


Receiver 


1 


" class Features" 


Lexicon [Feature] 


Cleared 


2 


" instar.ceFeaCures " 


Lexicon [Feature] 


Cleared 


3 


" isAbstract" 


true 


false 


4 


"sealedClassFeatures " 


Set [Identifier! 3 


Cleared 


5 


"sealedlnstanceFeatures " 


Set [Identifier ! ] 


Cleared 


6 


"superclasses " 


List [Identifier : ] 1 


' Object 




"vocabulary" 


Lexicon [Citation] 


Cleared 



'The receiver supplies a list cf one identifier, that of 
class "Object". In a class, this is "List [Class] " , and 
the receiver supplies a list of one class, class "Object". 

5.2.17 Lexicon 

An example of this class is encoded using the primary 
palette with which an example of class "Dictionary" is 
encoded . 

Note : The "constraint" attribute of a lexicon is fixed 

by the Instruction Set. 

5.2.18 List 

An example of this class is encoded using the primary 
palette in Table B.19. 



TABLE B.19 
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I 


Attribute 


Sender 


Receiver 








M 


" items " 


List [Object] ! 





5.2.19 Method 

An example of this class is encoded using the primary 
palette in Table B.20. 





TABLE 3.20 


it 


Attribute 


Sender 


Rece Lver 


l 


"procedure " 


Procedure 


Cleared 


2 


"variables " 


List [Identifier! j 


Cleared 



5.2.20 Mix-in 

The secondary palette is that in Table B.21. 



TABLE B.21 


I 


Attribute 


Sender 


Receiver 


-L 


"citation " 


Citaticn 


Absent 


2 


" constraint " 


Constraint 


Absent 


3 


name 


Teiename 


Absent 

-rJ 



A hashed object's "hash" attribute and an 
interchanged object's "digest" attribute are 
computed by the object. 



5.2.21 Operation 

An example of this class is encoded using the primary 
palette in Table B.22. 
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5 



10 





TABLE 3.22 


I 


Attribute 


Sender 


Receiver 


1 


excect ions 


Set [Identifier : ] 1 


Cleared 


2 


is?ubl ic 


true 


false 


3 


arguments 


List [Constraint] 


Nil 


4 


result 


Constraint 


Nil 



'In a class, this is "Set [Class J " . Each class is Exception 
20 or a subclass of it . 

5.2.22 Package 

10 An example of this class is encoded using the primary 

25 palette in Table B.23. 



30 



35 



TABLE 3.23 


I 


Attribute 


Sender 


Receiver 


M 


"citation" 


Citation- 




M 


" items" 


List [Class] - 





Note: The "constraint" attribute of a package is fixed 

by the Instructor Set. 

40 

5.2.23 Pattern 

An example of this class is encoded using the primary 
20 palette in Table 3.24. 



45 




TABLE B.24 I 




I 


Attribute 


Sender 


Receiver j 


50 


M 


"text" 


String 





55 
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5.2.24 Perrr.it 

An example of this class is encoded using the primary 
palette in the table. 







TABLE 3.25 




Attribute 


Sender 


Receiver 


1 


alicwar.ce 


Integer 


Of subject 


2 


canCharge 


true 


false 


3 


car.Go 


true 


false 


4 


canProcreate 


t rue 


false 




5 


canRestart 


true 


false 


6 


canSend 


true 


false 


7 


canTerminate 


true 


false 


3 


deadline 


Time 


Of subject 


9 


priority 


Integer 


Of subject 



5.2.25 Petition 



An example of this class is encoded using the primary 
palette in the table. 



I 


TABLE B.26 


Attribute 


Sender 


Receiver 


1 


"agentClass" 


Citation 


Nil 


2 


"agentName " 


Telename 


Nil 


3 


"maximumWait " 


Integer 


Nil 
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5.2.26 Random Stream 



An 


example of t 


his class is encoded 


using the primary 


palette 


in Table B.2 


T 
/ . 




TABLE B.2 7 


I 


At tr ibute 


Sender 


Receiver 








M 


" seed" 


Integer 





S . 2 . 27 Resource 

An example of this class is encoded using the primary 
palette in Table B.29. 



0 







TABLE B . 28 




1 


Attribute 


Sender 


Receiver 


1 


" condition*' 


Identifier I 


Undefined 1 


2 


" conditions " 




Undefined 1 



The "conditions" attribute comprises one identifier which 
5 equals the "condition" attribute. This identifier is 
undefined . 

Note : Any processes other than the subject awaiting 

use of the resource when the subject began its 
trip await the resource no longer, having been 
0 left behind. 

5.2.28 Set 

An example of this class is encoded using the primary 
palette with which an example of class "Collection" is 
encoded . 

5 5.2.29 Stack 

An example of this class is encoded using the primary 
palette in Table B.29. 



433 



EP 0 634 719 A2 



TA3LE B.29 




Attribute 


Sender 


Receiver 


M 


" items" 


Stack [Object] ! 





5.2.30 Teleaddress 
5 An example of this class is encoded using the primary 

palette in Table B.30. 



5 



0 



TABLE 3.3C 


ft 


Attribute 


Sender 


Receiver 


M 


"provider" 


OctetSt ring 




1 


" location " 


String 


Nil 


2 


" rout ingAdvice " 


List [OctetString] 


Cleared 


5.2.31 Telename 

An example of this class is encoded using 
palette in Table B.31. 


the primary 


TABLE 3.31 j 


|ft 


Attribute 


Sender 




M 


"authority " 


OctetString 


Receiver j 


1 


"identity" 


OctetString 


Nil | 


5.2.32 Telenumber 

An example of this class is encoded using 
palette in Table B.32. 


the primary 


TABLE 3.32 
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5 



I 


Attribute 


Sender 


Rece iver 


M 


" country" 


DialString 




M 


" telephone " 


DialString 




x 


"extension" 


DialString 


Nil 



15 

5 5.2.33 Ticket 

An example of this class is encoded using the primary 
palette in Table B.33. 



35 





TAJ 


3LE "-..33 


i 


Attribute 


Sender 


Receiver 




" travelNoces" 


Object 


Nil 


2 


"way" 


Way 


Nil 


3 


"desiredWait " 


Integer 


Nil 


4 


"dest inationAddress M 


Teleaddress 


Nil 


5 


"destinaticnCiass " 


Citation 


Nil 


6 


"dest inat ionName " 


Teiename 


Nil 


7 


"destinat ionPermit " 


Permit 


Nil 


3 


"maximumWai t " 


Integer 


Nil 



40 

5.2.34 Ticket Stub 

An example of this class is encoded using the prima rv 
20 palette in Table 3.34. 



45 


TABLE B.3 4 




I 


Attribute 


Sender 


Receiver 










50 


1 


" traveiNotes " 


Object 


Nil 



55 
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TABLE 3.3 4 


2 


"way" 


Way 


Nil 


5.2.35 Time 

An example of this class is encoded using the primary 
palette in Table B.35. 




TABLE B.3 5 1 


i 


Attribute 


Sender 


Receiver 


i 


"ds t " 


Integer 




2 


" second" 


Integer 




3 


" zone " 


Integer 





0 5.2.36 Trip Exception 

An example of this class is encoded using the primary 
palette in Table B.36. 



0 



TABLE B.3 6 


1 


Attribute 


Sender 


Receiver 


M 


" ticketStub" 


TicketStub 


Nil 


5.2.37 Unexpected Exceot ion 




An example of this class is encoded using 
palette in Table 3.37. 


the primary 


1 TABLE B.37 


r 


Attribute 


Sender 


Rece i ver 


M 


" except ion" 


Except ion 
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S.2.3S Way 

An example of c his class is encoded using the primary 
palette in Table 3.33. 


TABLE 3 . 38 




Attribute 


Sender 


R e c e iver 


1 


" authent icator" 


Authent icator 


Nil 


2 


"means " 


Means 


Nil 


3 


"name " 


Tele name 


Nil 



5 . 3 Encoding Classes 

The encoding palettes for the encoding classes are 
defined below. 

5.3.1 Catch Frame 



An example of this class is encoded using the primary 
palette in Table 3.39. 



TABLE 3.3 9 


4 


Attribute 


Sender 


Receiver 


M 


"position " 


Integer 




M 


"procedure " 


Procedure 




M 


"exception" 


Class 





5.3.2 Collection Stream 

An example of this class is encoded using the primary 
palette in Table B.40. 



TABLE 3.4 0 
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Attribute 


Sender 


Receiver 


i 


"position" 


Integer 


Nil 


2 


" source " 


Collection [Object] 


Mil 



5.3.3 Predefined Frame 



An example of this class is encoded using the primary 
palette in Table B . 4 1 . 



TABLE B.41 




Attribute 


Sender 


Receiver 


M 


"position" 


Integer 




M 


"procedure " 


Frccedure 





5.3.4 Repeat Frame 

An example of this class is encoded using the primary 
palette in Table 3.42. 



TABLE B.4 2 


I 


Attribute 


Sender 


Receiver 


M 


"position" 


Integer 




M 


"procedure " 


Frccedure 




i 


" repetit ionsSoFar" 


Integer 


1 


2 


"repetitions" 


Integer 


1 



> 5.3.5 Restrict Frame 

An example of this class is encoded using the primary 
palette in Table 3.43. 
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20 



TABLE 3.4 3 




Attribute 


Sender 


Receiver 


M 


"position" 


Integer 




M 


"procedure " 


Procedure 




M 


"permit " 


Permit 




5.3.6 


Send Frame 






An 

palette 


example of this class is encoded using 
in Table 3.44. 


the primary 




TABLE 3.44 


jl 


Attribute 


Sender 


Receiver 








I M 


"tickets" 


List [Ticket] ! 





30 



35 



40 



45 



50 



■3.7 Use Frame 

An example of this class is encoded using the primary 



palette in Table 3.45. 



TABLE B.4 5 




Attribute 


Sender 


Receiver 


M 


"position" 


Intege r 




M 


"procedure" 


Procedure 




M 


" resource" 


Resource 





20 5 • 3 . 8 User-defined Fram^ 

An example of this class is encoded using the primary 
palette in Table B . 46 . 

TABLE 3.46 



55 
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5 



10 



25 



£ 


Attribute 


Sender 


Receiver 








M 


"posit ion" 


Integer 






" responder" 


Object 


Agent 1 


2 


"stack" 


Stack [Object] ! 


Cleared 


3 


"variables " 


List [Object] ! 


Cleared 


: The agent of whose frames 
5.3.9 While Frame 


attribute this frame 


i is an item. 


An example of this class is encoded using the primary- 
palette in Table B.47. 






TABLE B.4 7 




Attribute 


Sender 


Receiver 


M 


"position" 


Integer 




M 


"procedure" 


Procedure 




M 


"precondition" 


Executed 




1 


" is Precondition" 


true 


false 



35 



40 



45 



50 
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APPENDIX C 

5 Copyright ( ~ General Magic, Inc. 1992, 1S93. All Rights 

Reserved 

w The following table of contents is to assist the 

5 reader in understanding the organization of and locaci: 
information within this appendix. 
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Engine 


4 . 2 


Platform 


4 . 3 


Dest inat ion 


4 . 4 


Failure 


5 5 . 


ROUTING 




Routing Algorithm 


6 . 


INTERFACE IN C+ + 




Interface description 




Tasks 


1 0 


CI Class 


1 . 


TELESCRIPT INTERFACE OBJECTS 


/ . 1 


Interface Conventions 


7 . 2 


TsCharacter 


7 . 3 


TsDestination 


lb / . 4 


TsDestinat ionList 


7 . 5 


TsExistingConnect ionMeans 


7 . 6 


Tslnteger 


7 . 7 


TsIntegerList 


7 . 8 


TsMeans 


20 7.9 


TsObjSpecif ier 


7.10 


TsOctet 


7.11 


TsOctets 


7.12 


TsPSTNMeans 


7.13 


TsReservableMeans 


25 7.14 


TsReservation 


7. 15 


TsString 


7 . 16 


TsTeleaddress 


7. 17 


TsTelename 


7 . 18 


TsTelenumber 


30 7 . 19 


TsWay 


1 . 


INTRODUCTION 



Overview 

This appendix defines the "communication services" 
that a Telescripc engine can obtain from the platform on 
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which it runs. Two engines employ these services to 
transfer the representation of an "agent" from a place in 
5 one engine to a place in the other, as required by 

Telescript's "go" and "send" operations. 
5 This appendix has two main pares. First, this 

apoendix describes the comnunicat ion services that a 

w 

Telescript engine requires in an abstract way, using 
Teiescript to describe the interface between engine and 
platform. Second, this appendix documents a C+ + 
is 10 "application programming interface" (API) which provides 
those services. 

Organization 

20 

This appendix is divided into seven sections. 
Section I is this introduction. Section 2 describes the 
15 basic concepts of the interface. Section 3 describes some 
25 additional Telescript classes. Section 4 specifies the 

interface in Telescript. Section 5 describes a transfer 
in more detail. Section 6 describes a C++ API which 
implements the interface. Section 7 describes C++ 
30 20 representations of Telescript classes which are used in 
the API. 

References 

35 

This appendix relies upon Appendix A of this 
disclosure . 

40 25 L INTERFACE CONCEPTS 

This section of this appendix describes the basic 
concepts of Telescript communication and communication 
interfaces. Many of the objects described here have 
45 direct representations in the Telescript instruction set 

30 or in the communication interface of the engine. 

2 . 1 Telename 
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Telescript supports the movement of objects between 
places and specifically between engines. Every place in 
the Telescript universe is assigned a distinct "telename" . 
Tele names have two attributes, an "authority" and an 
5 " identity" . 

Telescript supports telenames, whether assigned or 
otherwise. An "assigned telename", associated with an 
object by a Telescript engine, always contains both an 
authority and an identity. A telename which is not 
.0 "assigned" purports to identify one or more Telescript 
objects- A telename which is not "assigned" can have its 
identity attribute omitted, in which case the telename can 
actually identify several objects. 

2 . 2 Network 

5 A Telescript "network" comprises one or more regions. 

The network may not fully interconnect all of its regions 
and "point-to-point" transfer of information may not be 
possible between any two of them. Regions are 
interconnected, however, to the extent that the network 

0 can provide "store-and- forward" transfer of information 
between any two of them. 

2 . 3 Engine 

An "engine" is a computer process that implements the 
abstractions of the Telescript instruction set. An engine 
5 does this, in part, by communicating with other engines. 
An engine is denoted by an assigned telename. 

2 . 4 Platform 

A "platform" is a collection of hardware and software 
that supports one or more engines. A platform enables 
0 engines to communicate with ether engines on the same 
platform and on other platforms to which the platform is 
connected. 
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2 . 5 Region 

A " region" comprises the engines and supporting 
platforms operated by an individual or organization. 

A region fully interconnects the platforms the region 
contains. Thus the region enables the point-to-point 
transfer of information between any two of these 
platforms. Each region contains one or more platforms 
that provide access to and egress from the region. It is 
by means of these platforms that regions are 
interconnected to form a network. A region is denoted by 
a telename in which the identity attribute is omitted. 



2 . 6 Outoost 

A region can have an outpost in another region. An 
"outpost" is a place in a region which routes traffic from 
that region to the outpost's region. 



2 . 7 Domain 

A "domain" is a region, together with all of its 
outposts in other regions . 

2 . 8 Transfer 

A "transfer" is the conveyance of a transfer unit 
from one engine, the "source engine", to another, the 
"destination engine" . 

A transfer unit specifies a "destination" which can 
be used to route the transfer. Additionally, a way can be 
provided which can influence the route and "transport" 
used for the transfer. 



2 . 9 Transfer Unit 

A "transfer unit" is conveyed between engines in a 
transfer. A transfer unit consists of an octet string, 
and a destination. These are the only data items that are 
delivered end to end between engines. Additional data is 
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involved in specifying the transfer to the "originating 
platform" and in receiving a transfer at the destination. 

2 . 10 Destination 

A "destination" describes the ultimate destination of 
5 a transfer unit. 

2 . 11 Transfer Group 

The Telescript "send" operation, which is described 
in Appendix A, can result in the same octet string being 
delivered to several destinations. A "transfer group" is 

L0 a collection of transfer units and their associated 

destinations, together with one copy of the octet string 
being conveyed. 

A transfer group logically represents its component 
transfer units. A platform can break up a single transfer 

.5 group into multiple smaller transfer groups and/or single 
transfer units. 

2 . 12 Way 

A "way" specifies a region or engine, a means of 
communicating with the region or engine, and 
0 "authentication information" used to do so. 

A transfer cut of an engine can specify a way, i.e, 
the "way out", which defines communication requirements 
for the transfer. Incoming transfers provide engines with 
a way, i.e., the "way back", which can be used as the way 
5 out in subsequent transfers towards the original source. 

2.13 Means 

A "means" specifies a type of transport to be used 
for a transfer, e.g., wireline or wireless network. A 
means contains transport specific data such as a "quality 
0 of service" parameter or the telephone number for a " PSTN" 
connection . 
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A "reservable means" specifies a type of transport 
for which a reservation is honored. 

2 . 14 Reservation 

A "reservation" is a request that a connection 
5 established by a platform as the result of a transfer be 
maintained for some period of time. Reservations are 
hints to allow a connection to be used for multiple 
transfers . 

A reservation has meaning only when a transfer 
0 specifies a way with a reservable means. 

2 . 15 Rank 

Some transfers may be considered "privileged" . A 
"rank" is an indication of privilege. It is an integer, 
the value zero meaning unprivileged. The meaning of non^ 
5 zero values is source region specific. In inter-region 
transfers, a rank can be regarded as a hint which can be 
changed or ignored. 

3 . Communicat ion Classes 

This section defines additional Telescript classes 
0 which are not present in Appendix A of this disclosure. 

3 . 1 Reservation 
Object 

• Reservation 

Class 
5 Reservation : 

interface ( ) = (...); 

Public Instance Attributes 
id: 

Integer; 
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An identifier for a reservation created by a 
platform. 

3 . 2 Reservable Means 
Obj ect 
5 • Means 

• • Reservable Means 



Class 

15 t ReservableMeans : 

abstract interface (Means) = (...); 



20 



10 Public Instance Attributes 
reservation : 
Reservation; 



An identifier for a reservation created by a 
platform . 



15 3_^1 PSTN Means 
Object 

• Means 

• • Reservable Means 

• • • PSTN Means 



40 



45 



50 



20 Class 

PSTNMeans : 

interface (ReservableMeans) = (...); 

Public Instance Attributes 
telephoneNumber : 
25 Telenumber ; 

The telephone number to be used for this trip. 
3 . 4 Existing Connection Means 



55 
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Obj ect 

• Means 

• • Reservable Means 

• • • Existing Connection Means 

5 Class 

Exist ingConnect ionMeans : 

interface (ReservableMeans ) = (...); 

Public Instance Attributes 
connect ionID : 
0 Octets; 

A identifier which a platform can use to identify a 
connection . 

4 . INTERFACE IN TELESCRI PT 

In this section, the interface between an engine am 
5 its platform is specified as if both were Telescript 
objects, which they are not. It is intended that this 
definition be considered generic, i.e. independent of 
specific programming languages used to implement engines 
and platforms. 

The following Telescript class definitions are used 
in this interface. See Appendix A and Section 3 of this 
Appendix for their definitions: 

Integer 
List 

OctetStrina 
Telename 
Teleaddress 
Way 

Reservation 
4 . 1 Engine 
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Object 

• Engine 



Class 

Engine : 

interface ( ) = {...); 



Public Instance Operations 
transfer In : 
op ( 

octets: OccetString; 
destinations: List [Destination] ; 
rank: Integer; 
way : Way ; 

timeAdjust : Integer) 
throws Transfer I nFa i led ; 



Delivers one or more transfer units associated with a 
single transfer group to the engine. The transfer units 
are represented by the octets, destinations and rank. The 
way back {argument "way") contains the telename of the 
engine which performed operation M transf erOut " . The way 
back can provide an existing connection means which can be 
used to make a return trip. 

Argument "timeAdjust" is the number of seconds by 
which the clock of the source platform trails the clock of 
the destination platfcrm. The responder can use this 
information to adjust certain times that were generated 
relative to the source engine's clock. 

The "Transf erlnFailed" exception is thrown if the 
engine is unable to receive che transfer units. 



transf erFailed : 
op ( 

failure: Failure; 
octets : OctetString; 
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destinations: List [Destination]; 
rank: Integer; 
way: Way; 

timeAdjust: Integer) 
5 throws Transf erFai ledFailed ; 

Delivers one or more failed transfer units associate 
with a single transfer group to the engine. The 
parameters for this operation are identical to those of 
operation "tra.nsferln" with the addition of the reason fo 
0 the failure (argument "failure") . 

It is possible that a " transf erFailed" operation can 
happen before a " transf erCutComplete " has been received a 
the source engine for the transfer group. 

If failure is " invalidMeans" , the responder will be 
5 the source engine if possible. 

An exception is thrown if the responder is unable to 
receive the failed transfer units 
( "Transf erFailedFailed" ) . 

transf erOut Failed : 
G op ( 

reason: Failure; 
grcupID: Inceger; 
failures: List [Integer] | Nil) 
throws UnknownTransf erGroup, UnkncwnTransf erUni t ; 

5 One or more transfer units in the transfer group 

(argument "groupID" ) has failed. The cause of the failure 
is given in argument "reason". The particular units that 
have failed are identified by a list (argument "failures") 
of integer indices into the original list of destinations 

0 given at performance of operation transf erOut. List 
indices begin at one, which identifies the first unit in 
the transfer group. 
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If a list is not provided, i.e, if the value of 
argument "failures", is nil, every transfer in the group 
has failed. This is identical to a list which enumerates 
all the units in the original group. 

5 An exception is thrown if the responder did not 

previously perform a " transf erOut " operation denoted by 
argument "groupID" ( "UnknownTransf erGroup" ) , or one of the 
items of argument "failures" is not a valid index into the 
destination list for this transfer group 

0 ( "UnknownTransf erUnit 11 } . 

transf erOutComplete : 

op (groupID: Integer; serialNumber : Integer} 
throws UnknownTransf erGroup ; 

Indicates that the "'transf erOut " operation associated 
5 with a particular transfer group (argument "groupID") has 
been completed. In particular there can be no further 
"transf erCutFai led" operations for this group. Any 
resources associated with the transfer units in this group 
may be released. 

An exception is thrown if the responder did not 
previously perform a transferOut operation denoted by 
argument "groupID" ( "UnknownTransf erGroup" ) . 

4 . 2 Platform 
Object 

• Platform 
Class 

Platform : 

interface (}=(...); 

Construct ion 

initialize : 

op (engine: Telename) ; 
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Initializes the responder for use by the named engine 
(argument "engine"} . 

Public Instance Operations 
transf erOut : 
5 cp (octets: OctetString; 

destinations: List [Destination]; 
rank: Integer; 
way: Way | Nil; 
desiredDurat ion : Integer; 
0 maximumDurat ion : Integer; 

groupID: Integer) 
throws InvaiidDestinat ion, InvaiidWay; 

Requests delivery of a transfer group, which is 
defined by arguments "octets", "destinations", and "rank", 

5 to one or more destination engines. The group is 

identified by the group id (argument "groupID" ) . This 
operation results in one of operations " transf erln" , 
M transf erOutFa iled" or " transf erFai led" subsequently 
referencing each of the transfer units that make up this 

0 group . 

The rank (argument "rank") specifies whether this 
transfer is privileged. 

If argument "way" is non-net a nil, it will be used 
to route the transfer. 

5 The desired duration of the transfer is specified in 

seconds (argument " desiredDurat ion" ) . This is the maximum 
elapsed time desired for the transfer. A value of zero 
for the desired duration indicates that no desired 
duration is associated with this transfer. 

0 The maximum allowed duration for the transfer is 

specified in seconds (argument "maximumDurat ion" ) . This 
is the maximum time allowed for the transfer. If 
operation " transf erOutCompie te " has not happened this many 
seconds after the " transf erOut " operation, then the effect 
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is the same as though a " f ailTransf er " operation is 
performed for this group. A value of zero for the maximum 
duration indicates that no maximum duration is associated 
with this transfer. 

An exception is thrown if the destination list is 
invalid ( " inval idDestinat ion" ) or if argument "way" is 
supplied but has no non-nil attributes C " inval idWay" ) . 

f ailTransf er : 

op {groupID: Integer) 

throws UnknownTransf erGroup ; 

Requests that all pending transfer units in che 
transfer group identified by the group id {argument 
"groupID") be failed. 

It is possible that not all transfer units in a 
transfer group can be failed. Transfer units failed as a 
result of this operation will cause one or more 
" transf erOutFailed" operations followed by a 
" transf erComplete " . 

An exception is thrown if the group id was not used 
in a previous " transf erOut " (operation 
"UnknownTransf erGroup" ) . 

makeReservation : 

op (duration: Integer) Reservation 
throws CannotReserve ; 

Returns a new reservation cf duration (argument 
"duration") seconds. The reservation becomes active when 
the reservation is used in a reservable means for a 
subsequent "transf erOut " operation . 

Once a reservation expires, che reservation is no 
longer valid and transfers will fail if they attempt to 
use the reservation. 
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Reservations should be canceled with the 
" resetReservation" operation when they are no longer 
required. Platforms can impose maximum lifetimes on 
unused reservations. 
5 The "CannotReserve" exception is thrown if the 

responder is unable :o provide a reservation. 

resetReservation : 

cp {reservation: Reservation, duration: Integer) 
throws UnknownReservaticn, Inval idReservat ion ; 

0 The duration of an existing reservation (argument 

"reservation"} is changed to duration seconds. If the 
reservation is active when this operation is invoked, the 
effect is the same as if a "transfer-Out" operation had 
just been done with a reservation of the new duration. 

5 Setting the duration zo zero cancels a reservation. 

A canceled reservation is no longer valid. 

An exception is thrown if reservation was not 
obtained with a prior " makeReservat ion" operation 
( "unknownReservation" ) , cr if the reservation is no longer 

0 valid ( " invalidReservaticn" ) . 

4 . 3 Destination 
Object 

• Destination 

Class 
5 Destination : 

interface ( ) = {...;■; 

Construction 

initialize : 
op ( 

0 name: Telename | Nil; 

address: Teleaddress J Nil; 
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5 



10 



data: OctetString j Nil) ; 

Sets the responder's native attributes to the like- 
named arguments (arguments "name", "address", and "data"), 

If all the attributes of a destination are nils, the 
5 destination is invalid. 

Private Instance Attributes 
address : 

Teleaddress | Nil; 



20 The address of the destination. 

10 data : 
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OctetString ] Nil; 

Engine specific data associated with a transfer unit 
name : 

Telename [ Nil; 

15 The name of the destination. 

4 . 4 Failure 
Object 

• Failure 

Class 
20 Failure : 

interface ( ) = (...); 

Private Instance Attributes 
reason : 
Integer ; 
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The reason for the failure of a transfer. The reason 
is represented as an integer enumeration shown in table 
C. 1 . 

TABLE C. 1 



5 


i 


i n va lid Destination 


An invalid destination was 
provided . 




2 


invaiidWay 


An invalid way was 
provided . 




3 


invalidNeans 


An invalid means was 
provided . 




4 


invalidReservation 


An invalid reservation was 
provided. 




5 


noDestinations 


No destinations were 
specified . 




6 


maximumDurat ionExceeded 


The maximum duration has 




7 


trans f ersF ailed 


f ailTransf ers was called. 




e 


noLiCcalResources 


The platform failed to get 
some resource . 




9 


destinationUnreachable 


A transfer unit was 
undeliverable . 




10 


trans f erlnFailed 


transferln failed at the 
remote engine . 


5 


11 


securityViolat ion 


There was an authentication 
f ai lure . 




12 


possible Duplicate 


May have been delivered. 
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A platform can provide additional failure tyoes. 

5 . ROUTING 

The "transferOut" operation of a transfer unit 
typically results in the "transferln" operation of the 

5 same unit at a different engine. If the transfer fails at 
the source platform, the transfer unit is failed with a 
"transferOutFailed" operation at the source engine. If 
the transfer unit is successfully transferred from the 
source platform but does not participate in a successful 

3 "transferln" op n = operation at the destination engine, it 
is failed to an engine with " transf erFailed" op". 

The "transferOut" op n of a transfer group is logically 
equivalent to N "transferOut" op n s of the component 
transfer units. The value of rank, desired and maximum 

> durations and the way are identical for all the transfers. 
The list of destinations can imply op n "transferln" occurs 
at more than one destination engine. 

Typically, a platform will examine the list of 
destinations in a group and attempt to deliver the units 

> with the minimum number of "transferln" op n s at destination 
engines. This implies that transfer units destined for 
the same engine will be transported and delivered as a 
group . 

Routing Algorithm 

If a way is provided in a performance of 
"transferOut" op\ the platform uses it to route the 
transfer. If a way is not provided, the platform must 
determine the destination engine. The steps for 
determining the destination engine based on the name and 
address associated with a transfer unit are: 

<start > 
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if the name is present but the address is not 

<use the name> 
if the address is present but the name is not 
if the provider is the current region 

find the corresponding name or <fail> 
set the name attribute of destination to 



name 



<start> 

else 

15 10 <use the address> 



if both the name and address are present 

if the provider is the current region 
<use the name> 

else 

15 <use the address> 



<use the name>: 

if. the authority is the current region 
if the identity is present 

determine the destination engine 
20 from the identity or <fail> 

else 

determine the destination engine 
from the location or <fail> 

else 

25 route to the engine that contains the 

outpost of authority or <fail> 

<use the address> : 

if the provider is known 

route to the engine containing 
30 the outpost of the provider 

else 

for each of the providers in the routing advice 
if it is the current recion 
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remove it from the routing advice 

else 

if the provider is known 

route to the engine containing 
5 the outpost of provider 

if there is still no route then <fail> 

<fail>: 

if the provider is the current region 
fail the transfer 

0 else 

if there is a default engine 
route to it 

else 

fail the transfer 

5 6^ INTERFACE IN C+ + 

This section describes a C++ implementation of the 
engine-platform interface. This interface is derived from 
the Telescript specification of the interface in Section 
4 . 

3 By necessity, the interface presented here reflects 

aspects of the current Telescript engine's implementation. 
In particular the C++ API includes operations on the 
engine which do not appear m the generic interface. 

Interface description 
» The engine object is represented by the C++ class 

"CI". Operations on the engine object are provided as 
member functions of CI. 

The platform object is represented by a subclass of 
CI. The provider of a platform subclasses of CI and 
implements virtual functions of CI which represent the 
platform operations. 

The Telescript objects which appear as parameters to 
the operations on both engine and platform are represented 
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by a number cf Cfr classes which implement limited 
representations of Telescript objects. For example there 
is a "Tslnteger" class which represents a Telescript 
"Integer" wherever "Tslnteger" appears in the API. A 

5 complete description of these Telescript Interface Objects 
appears in the next section of this appendix. 

Exceptions, which are specified in the Telescript 
representation of the interface, are implemented in the 
API as an enumerated type which is returned from all 

0 operations on both engine and platform. 

The storage for the data elements passed between 
engine and platform is owned by the caller of an 
operation. The storage can be reclaimed when an operation 
is complete. The only exception to this is the 

5 "transfer-Cut " operation. The engine does not reclaim the 
elements of a transfer out until the corresponding 
"transferOutComplete" operation has been performed. 

Tasks 

The engine is implemented as multiple cc-operating 
0 tasks running as separate threads with a non-preemptive 
scheduler. An instance of the CI class is run as a thread 
in the engine. A subclass of the CI class provides a 
function, "mainO", which is called once and should only 
return when additional operations on the platform are no 
5 longer supported. 

"mainO" is expected to yield to the engine scheduler 
when there are no pending " transf erln" operations. 
"mainO" does this by calling "waitO". "waitO" takes 
an argument which is the number of milliseconds that the 
0 CI is willing to yield for. Typically the engine will not 
reschedule the CI's task until at least that amount of 
time has passed. An argument of zero to "waitO" implies 
that the CI is yielding but would like to be rescheduled 
as scon as possible by the engine scheduler. 
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An argument of -1 to "waitO" has the meaning that 
the CI wishes to block indefinitely. in this case, the CI 
is expected to call "satisfy!) " on the engine when the CI 
wishes to be rescheduled. "satisfy*)" will cause a thread 
5 blocked in wait to resume execution as soon as the engine 
schedules the thread. This latter scheme would be 
appropriate for a CI implementation which was delivered an 
asynchronous event when there were new communications 
requests . 

0 On some operating systems, a CI implementation may 
wish to yield to the engine scheduler and be rescheduled 
when a file descriptor becomes ready. The 11 wait fd" 
operation specifies a file descriptor to wait on and may . 
be used in conjunction with "waitO" to select on multiple 

5 file descriptors with a timeout. 

Performances of cp n "transfer-Out" are executed in the 
thread of the calling Telescript processes and not in the 
thread of the CI task. 

Operations on both engine and platform must execute 
3 relatively quickly, if necessary by queuing work to be 
scheduled later. Both engine and platform should not 
block for extended periods of time. 

In extreme situations, the volume of "transfer-Out" 
operations may overwhelm the buffering provided by a CI . 

1 In this situation, the CI can call "stop!)" which will 
have the effect of preventing all further calls to op n 
"transferOut". A subsequent call to "start ()» will resume 
output, possibly rescheduling engine tasks that had to be 
halted as a result cf the blockage. 

CI Class 

Construction 
CI : 

CI (TsTelename *name) ; 
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Constructs a new CI object. "name" is the telename 
of the engine which will use this CI. 

-CI : 

virtual -CI () 
5 Shuts down and destroys this CI. 

main : 

virtual long mainO = 0; 

The main loop of a CI . This is called some time 
after construction. The CI should yield to the engine, 
10 e.g. with "waitO" , during the execution of this function. 



Engine Operations 
25 transf erln : 

TsStatus transferln (TsOctets *bagOfBits, 

TsDest inationList *destList, 

15 unsigned int rank, 

TsWay *wayBack, 
int timeAdjust) ; 

Transfers one or more transfer units into the enaine. 
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trans ferFai led : 

TsStatus transferFailed (TsFailure failure, 

TsOctets *bagOf Bits, 

5 TsDestinaticnList *destList, 
unsigned int rank, 

TsWay *wayBack, int 

timeAdjust) ; 

Transfers one or more failed transfer units into the 
10 engine. 

transf erOutFail ed • 

TsStatus transferOutFailed (TsFailure failure, 

unsigned int groupld, 
TsIntegerList 

15 *list) ; 

Identifies one or more transfer units which have 
failed a previous performance of op n " transf erOut " from 
this engine . 

transf erQutComp l f>r<=> ■ 

TsStatus transferCutCompiete {unsigned int groupld, 

unsigned int 

transferSN) ; 

Indicates that the transfer of a transfer group 
(argument "groupld") has completed. The storage 
5 associated with all the transfer units in this group can 
be reclaimed. 

Platform Qperatinng 
transf erOut 

virtual TsStatus transferOut (TsOctets *bagOfBits, 
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TsDestinationList *destList , 
unsigned int rank, 
TsWay *wayOut , 

unsigned int desiredDuration , 
5 unsigned int maximumDurat ion, 

unsigned int groupld) = 0; 

Transfer the transfer units in this transfer group to 
their respective destinations {argument "destList"). 

f ailTransf er : 

.0 virtual TsStatus failTransfer (unsigned int groupld) 

- 0; 

Fail all the transfer units associated with the 
transfer group (argument "groupld") . 

makeReservation : 
5 virtual TsStatus makeReservation (unsigned int 

duration, TsReservat ion 

Reservation) = 0; 

Request a new reservation (argument "reservation") 
with the specified duration (argument "duration") . 

0 resetReservation : 

virtual TsStatus rese cReserva: ion (TsReservat ion 

reservation, unsigned int duration) = 

C ; 

Reset the duration of reservation to the new duration 
5 (argument "duration"). A duration of zero has the effect 
of canceling the reservation. 

Task Operations 
wait : 
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void wait (long msec) ; 

Yields the current engine thread for "msec" 
milliseconds. The function will return when this thread 
is rescheduled. If argument "msec" is zero, the thread 
5 will be rescheduled as scon as the engine scheduling 
policy allows. If argument "msec" is -1 this call to 
"waitO" will not return until "satisfy ()" (see below) is 
called or a file descriptor specified with "waitfdO" 
becomes ready. 

0 satisfy: 

void satisfy ( ) ,• 

Causes the CI thread to be rescheduled if the CI 
thread is blocked in a "waitO" call. 

wait f d : 

5 void waitfd (int fd, short mask); 

Specifies that subsequent "wait () " calls will return 
if the file descriptor "fd" becomes ready for either 
reading or writing as specified by "mask" . "mask" is a 
bitmask constructed by OR-ing the values "POLLIN" and 
0 "POLLOUT" which select for the file descriptor being 

readable and writable respectively. A "mask" of zero has 
the meaning that this file descriptor should no longer 
affect the operation of "wait 0 " . 

waitresul t : 
5 short waitresult (int fd) ; 

Returns a bitmask which can be used to test whether 
the file descriptor "fd" may have become ready during the 
previous "waitO" call. The result is a bitmask with the 
bits "POLLIN" and "POLLOUT" set if they were specified in 
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"waitfdO" and the file descriptor became ready for read 
5 or write respectively. 

stop : 

void stop ( ) ; 

10 

5 Causes the engine to throttle all n transf erOut " op n s 

for this CI. No further transfers will be requested of 
15 this CI, which may cause Telescript agents executing op" 

"go" or "send" to block. The CI should only invoke this 
operation if the CI would loose data by queuing further 
10 transfers. 

20 

start : 

void start ( ) ; 

25 „ 

informs tne engine that it should no longer throttle 

op n s . 

30 15 7^ TELESCRIPT INTERFACE OBJECTS 

To enable communication with external systems, e.g. 
other Telescript engines or non-Telescr ipt -based 
communicating systems, a Telescript engine must rely on 
35 communications services provided by a platform or 

20 operating system underlying the Telescript engine itself. 
To gain access to these services, the Telescript engine 
must support a mechanism to allow information to flow into 

40 . 

ana out of the Telescript abstraction. Specifically, to 
allow conversion between key Telescript objects and 
25 corresponding representations of these objects that are 
45 palatable to the underlying communication services. 

The Telescript Engine Interface Classes provide an 
abstract definition for a set of C++ classes that fulfill 
this need. The definition provided is abstract in that 
so 30 the C++ classes are not fully defined, but rather are 
described in terms of the Telescript engine's minimum 
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requirements on their functionality. Complete freedom is 
left to the implementcr of these classes as to their 
internal mechanisms and their relationship with the 
underlying communication services. 

5 7 . 1 Interface Conventions 

An implementation of the Telescript Engine Interface 

Classes must adhere to a set of conventions regarding the 

use of data items which pass across the class interfaces. 

These conventions are expressed in terms of rules of 
0 ownership, wherein ownership is defined as the right to 

modify and the responsibility to destroy a given piece of 

data . 

Unless otherwise stated, an implementation of the 
Telescript Engine Interface Classes must adhere to the 
5 following interface conventions: 

• For all functions that accept reference or pointer 
arguments, ownership of the referenced or pointed to 
data passes from the caller to the object called, 
such that the object has the right to modify the data 
and the responsibility to destroy the data at the 
appropriate time. 

• For all functions that return reference cr pointer 
values, ownership of the referenced or pointed to 
data is retained by the called object. However, the 
object guarantees that, until the next call to a 
function that can modify the object, the data 
referenced/pointed at will not change. 

• When destroyed, an object will destroy all data for 
which is has ownership. 

7 . 2 TsCharacter 

The "TsCharacter" type definition provides a limited 
C++ representation of the Telescript Character class, as 
defined in Appendix A of this disclosure. 
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An implementation of the " TsCharacter " type is 
required to be able to contain all ASCII characters. Thi 
is a minimum requirement. Preferably, an implementation 
of the "TsCharacter" type can contain all Unicode 
characters . 

7 . 3 TsDestinat ion 

The "TsDestination" class provides a C++ 
representation of the Telescript Destination class, as 
defined in Section 4 of this Appendix. An implementation 
of the "TsDestination" class shall provide, at a minimum, 
the following functionality. 

class TsDestination 

{ 

public : 

TsDestination (TsTeleaddress * teleaddress, 
TsTelename * telename, 
TsOctets * data) ; 

-TsTeleaddress () ; 

const TsTeleaddress * getTeleaddress (} const; 
const TsTelename * getTelename (} const; 
const TsOctets * getData {) const; 

}; 

Construction 

TsDestination : 

TsDestination (TsTeleaddress * teleaddress, 

TsTelename * telename, 
TsOctets * data) 

Constructs a new "TsDestination" object. 

teleaddress 
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Either a pointer to a "TsTeleaddress" object that is 
to form the teleaddress value of the new "TsDestination" 
object, or the NULL pointer if the destination object is 
no contain no teleaddress value. 

5 telename 

Either a pointer to a "TsTelename" object that is to 
form the telename value of the new "TsDestination" object, 
or the NULL pointer if the destination object is to 
contain no telename value. 

0 data 

Either a pointer to a "TsOctets" object that is to 
form the destination data value of the new "TsDestination" 
object, or the NULL pointer if the destination object is 
to contain no destination data value. 



5 Destruction 

-TsDestination : 
-TsDestination () 



Destroys the "TsDestination" object. The 
"TsDestination" object and all data for which the object 
has ownership responsibility are destroyed. 

Data Access 

getTeleaddress : 

const TsTeleaddress * getTeleaddress (} const 

Returns either a pointer to the teleaddress value of 
the "TsDestination" object, or the NULL pointer if the 
destination object contains no teleaddress value. 

aetTeifin^mp • 

const TsTelename * getTelename 0 const 
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Returns either a pointer to the telename value of zY 
"TsDestination" object, or the NULL pointer if the 
destination object contains no telename value. 

aecData : 

5 const TsOctets * getData () const 

Returns either a pointer to the destination data 
value of -he "TsDestination" object, or the NULL pointer 
if the destination object contains no destination data 
value. 

10 7 . 4 TsDestinationList 

The "TsDestinationList" class provides a C++ 
representation of a Teiescript class "List" as defined in 
Appendix A of this disclosure, constrained to contain 
objects of the class "Destination". An implementation of 
15 the "TsDestinationList" class shall provide, at a minimum 
the following functionality, 
class TsDestinationList 
i 

public : 

0 TsDestinationList (); 

-TsDestinationList ( ) ; 

const TsDestination * nextDest ination 0; 
void reset {J ; 

size_t destinat ionCount () const; 

5 void appendDest ination (TsDestination * 

destination) ; 
i 



Construct ion 

TsDestinationList : 
0 TsDestinationList {} 
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Constructs an empty "TsDestinat ionList " object. 

Destruction 

-TsDestination-List : 
-TsDestinationList () 

5 Destroys a " TsDest inat ionList " object. The 

"TsDestinationList " object and ail data for which the 
object has ownership responsibility are destroyed. 

Data Access 

appendDestination : 
.0 void appendDestination (TsDest ination * destination) 

Appends a single destination, in the form of a 
"TsDestination" object to the list of destinations 
contained within the "TsDestinationList" object. 

destination 

5 A pointer to a "TsDestination" object conveying the 

destination to be appended to the list of destinations 
within the TsDestinationList object. 

next Pest ination : 

const TsDestination * nextDestinat ion (} 

0 Returns either a pointer to a destination, in the 

form of a "TsDestination" object, or the NULL pointer. 
Over multiple invocations, the "nextDestinat ion () n 
function returns the set of destinations contained within 
the "TsDestinationList" object in the order of their 

5 containment. Subsequent to return of the last destination 
and until the next invocation of the reset function, the 
"nextDestinationO " function returns the NULL pointer. 

reset : 
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void resec () 

Causes the next invocation of the "nextDest ination ( ) 
function to return the first destination contained within 
the "TsDestinationList" object. 

5 dest inat ionCount : 

size_c destinationCount () const 

Returns the number of destinations currently 
contained within the "TsDestinationList" object. 

7 . 5 TsExist inaConnect ionMeans 

D The "TsExistingConnectionMeans" class provides a 

representation of the Telescript " Exist ingConnect ionMeans 
class, as defined in Section 3 of this appendix. An 
implementation of the "TsExist ingConnect ionMeans " class 
shall provide, at a minimum, the following functionality. 

5 class TsExistingConnectionMeans : public 

TsReservableMeans 

( 

public : 

TsExistingConnectionMeans 
* (const TsReservation & reservation, 

TsOctets * connectionld) ; 

'-"sExist ingConnect ionMeans 0 ; 

const TsOctets * getConnect ionld () const; 
}; 

Construction 

TsExist iac- Connect ionMeans : 

TsExistingConnectionMeans (const TsReservation & 
reservation, 

TsOctets * connectionld) 
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Constructs a new "TsExistingCcnnecticnMeans" object. 



reservation 

A reference to a "TsReservation" object that is to 
form the reservation value of the "TsReservableMeans" 
super-class component of the new 
" TsExis t ingConnec t ionMeans " ob j ect . 

connect ionld 

A pointer to a "TsOctets" object that is to form the 
connection identifier value of the new 
"TsExistingConnectionMeans" object . 

Destruction 

-TsExistinq-ConnectionMeans : 
-TsExistingConnectionMeans ( ) 

Destroys the "TsExistingConnectionMeans" object. The 
"TsExistingConnectionMeans" object and all data for which 
the object has ownership responsibility are destroyed. 

Data Access 

get Connect ionld : 

consc TsOctets * getConnectionld () const 

Returns a pointer :o the connection identifier value 
contained within the "TsExistingConnectionMeans" object. 

7 . 6 Tslnteger 

The "Tslnteger" type definition provides a limited 

C++ representation of the Telescript class "Integer". 

An implementation of the "Tslnteger" type shall be 

capable of holding values in the range -2147483643 to 
+2147483647 inclusive. 
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7 . 7 TsIntegerList 

The "TsIntegerList" class provides a C+ + 
representation of a Telescript class "List", as defined in 
Appendix A of this disclosure, constrained to contain 
5 objects of che class "Integer" . An implementation of the 
"TsIntegerList" class shall provide, at a minimum, the 
following functionality, 
class TsIntegerList 
{ 

15 10 public: 

TsIntegerList ( ) ; 
-TsIntegerList {); 

const Tslnteger * nextlnteger (); 
void reset ( ) ; 
15 size_t integerCount () const; 
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void appendlnteger (Tslnteger integer) ; 

}; 

Construction 

TsIntegerList : 
20 TsIntegerList (} 

Constructs a new "TsIntegerList" object. 

Subsequent to construction and until the first 
invocation of the "appendlnteger () " function, the newly 
created integer list object will be empty. 

25 Destruction 

-TsIntegerList : 
-TsIntegerList 0 



Destroys a "TsIntegerList" object. The 
"TsIntegerList" object and all data for which the object 
50 30 has ownership responsibility are destroyed. 
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aocend Integer : 

void 'appendlnteger (Tslnteger integer) 

Appends a single integer, in the form of a 
"Tslnteger" object, to the list of integers contained 
5 within the TsIntegerList object. 

integer 

An integer value to be appended to the list of 
integers within the "TsIntegerList" object. 

next Integer : 
0 const Tslnteger * next Integer 0 

Returns either a pointer to an integer, in the form 
of a Tslnteger object, or the NULL pointer. Over multiple 
invocations, the "next Integer () " function returns the set 
of integers contained- within the "TsIntegerList" object in 
5 the order of their containment. Subsequent to return of 
the last integer and until "he next invocation of the 
reset function, the "next Integer () " function returns the 
NULL pointer . 

reset : 
0 void reset () 

Causes the next invocation of the " next Integer () " 
function to return the first integer contained within the 
"TsIntegerList" object . 

integerCount : 
5 size_t integerCount () const 

Returns the number of integers currently contained 
within the "TsIntegerList" object. 
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7.3 TsMeans 

The "TsMeans" class provides a C- + representation of 
the Telescript class "Means" as defined in Appendix A of 
this disclosure. An implementation cf the "TsMeans" shall 
5 provide, ac a minimum, the following functionality. 

class TsMeans 

{ 

public : 

typedef enum 
o { 

TsMeansType_PSTN =0, 
TsMeansType_Exist ingConnect ion = 1 
} Type; 

virtual -TsMeans () = 0; 
5 Type type () const; 

protected : 

TsMeans (Type type) ; 

}; 

Construction 
0 TsMeans : 

TsMeans (Type meansType) 

Constructs a new "TsMeans" object. 

meansType 

An enumeration specifying the means type value of the 
5 new "TsMeans" object. 

Destruction 

-TsMeans : 

virtual -TsMeans () 

Destroys the "TsDestinat ion " object. The 
0 "TsDestination" object and all data for which the object 
has ownership responsibility are destroyed. 
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Data Access 
type: 

Type type ( ) const 

Returns the means type value of the "TsMeans" object 

5 7 . 9 TsObj Specifier 

The "TsObjSpecif ier" provides a C+ + representation o 
a class of objects each of which denotes a protocol and 
distinguishes that protocol from other protocols. For 
example, a member of the class represented by 

0 "TsObjSpecif ier" can be used to denote a specific way of 
providing security. An implementation of the 
"TsObjSpecif ier" class shall provide, at a minimum, the 
following functionality. 

class TsObjSpecif ier 

{ 

public : 

TsObjSpecif ier (Tslnteger objld, 

TsOctets * namingAuthority) ; 
-TsObjSpecif ier () ; 
Tslnteger getObj Id C) const; 

const TsOctets * getNamingAuthority () const; 

} ; 

Construction 

TsObjSpecif ier : 

TsObjSpecif ier (Tslnteger objld, TsOctets * 
namingAuthority) 

Constructs a new TsObj Specif ier object. 
obi Id 

An integer value that is :o form the object 
identifier value of the new "TsObjSpecif ier" object. 
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namingAut hor i ty 

Either a pointer to a "TsOctets" object that is to 
form the naming authority value of the new 
"TsObjSpecif ier" object; or the NULL pointer, if the new 
5 "TsobjSpecif ier" object is to contain no naming authority 
value . 

Destruct ion 

-TsObi Scecif ier : 
-TsObjSpecif ier ( ) 

0 Destroys the "TsCbj Specif ier " object. The 

"TsObjSpecif ier" object: and all data for which the object 
has ownership responsibility are destroyed. 

Data Access 

qetObi Id : 
5 Tslnteger getObjld () const 

Returns the object identifier value contained within 
the "TsObjSpecif ier" object. 

get Naming- Authority: 

const TsOctets * getNamingAuthority () const 

0 Returns either a pointer to a "TsOctets" object 

conveying the naming authority value contained within the 
"TsObjSpecif ier" object; or the NULL pointer, if the 
"TsObjSpecif ier" object contains no naming authority 
value . 

5 7 • 10 TsOctet: 

The TsOctet 
Telescript class 
disclosure . 



type provides a C++ representation of the 
"Octet" as defined in Appendix A of this 
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The "TsOctet" type shall be defined as a C+ + unsigned 

char . 

7 . 11 TsOctets 

The "TsOctets" class provides a C + + representation of 
5 the Telescript class "Octets" as defined in Appendix A of 
this disclosure. An implementation cf the "TsOctets" 
class shall provide, at a minimum, the following 
functionality. 

class TsCctets 

10 { 

publ ic : 

enum CopyOwnership { makeCopy, ownCopy, 
borrowCopy } ; TsOctets (size_t size); 

TsOctets (size_t size, const TsOctet * data, 
15 CopyOwnership ownership = makeCopy) ; 

-TsOctets ();cor.st TsOctet * nextSeg (int & 
segSize); void reset (}; 

size_t size ( ) const ; 

void appendSeg (size_t size, const TsOctet * 

20 data) ; 



Construction 
TsOctets 

TsOctets "size_t size, TsOctet * data , CopyOwnership 
40 2 5 ownership) 

Constructs a "TsOctets" object from a single array of 
"TsOctet" objects. 

45 

size 

The number of octets to be contained within the new 
30 "TsOctets" object. 

50 J 
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data 

A pointer to an array of octets, i.e., "TsOctet" 
objects, to be contained within the new "TsOctets" object. 
The number of elements in the array must be greater than 
or equal to the value of "size". 

Note: For the case where "size" is zero, a zero length 

array must be provided by the caller. 

ownership 

An enumeration specifying the method by which the 
array of occets is to be incorporated into the new 
"TsOctets" object. The possible values are: 

"makeCcpy" : the data within the octet array must be 

incorporated into the new "TsOctets" object 
by the construction of a separate physical 
copy. Subsequent to the construction, the 
caller retains complete ownership of the 
original octet array. 
When the ownership argument specified is 
"makeCopy" , the octet array provided by the caller 
may be either statically, dynamically or 
automatically allocated. 

"ownCopy" : The data within the octet array can, at the 

implementation's discretion, be 
incorporated into the new "TsOctets" object 
directly, via the incorporation of the 
provided oct»-t array itself. Subsequent to 
the construction, the caller relinquishes 
ownership of the provided octet array to 
the new "TsOctets" object. 

When the ownership argument specified is 
"ownCopy", the octet array provided by the caller 
must be dynamically allocated. 
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"bcrrowCopy" : The data within the octet array can, at the 
implementation's discretion, be 
incorporated into the new "TsOctets" object 
directly, via the incorporation of the 
provided octet array itself. Subsequent to 
the construction of the "TsOctets" object 
and until its destruction, the caller loans 
the caller's ownership of the provided 
octet array to the new "TsOctets" object. 
For this duration, neither the caller nor 
the "TsOctets" object may modify or destroy 
the octet array. Upon destruction of the 
"TsOctets" object, complete ownership of 
the octet array passes back to the caller. 
15 When the ownership argument specified is 

"borrowCopy" , the octet array provided by the caller 
can be either statically, dynamically or 
automatically allocated. 



30 

20 



TsOctets : 

TsOctets (size_t eventualSi ze ) 



rv 



instructs an empty "TsOctets" object in preparation 
for the addition of data using the "appendSeg ( ) " function, 
which is described below. 

eventualSize 

25 The maximum number of octets to eventually be 

contained with the new "TsOctets" object. 

45 Destruction 

-TsOctets : 



rsOctets () 
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Destroys the "TsCctets" object. The "TsOctets" 
object and ail data fcr which the object has ownership 
responsibility are destroyed. 

Data Access 
5 apoendSea : 

void appendSeg (size_t size, 
TsOctet * data, 
CcpyOwnership ownership) 



Appends an array of octets, i.e., "TsOctet" objects 
10 to the set of octets already existing within the 
"TsCctets" object . 
Note : The effect of invoking this function upon a 

"TsOctets" object created by means of a 
constructor other than the "TsOctets", i.e., by 
25 15 means of argument "eventualSize" of the 

constructor function above, size "eventualSize" 
constructor is implementation defined. 
Additionally, the effect of appending more data 
than that declared in the "eventualSize" 
20 parameter of the constructor is also 

implementation defined. 



size 

The number of octets to be appended to the "TsOctets" 
obj ect . 

2 5 data 

A pointer to an array of octets, i.e. "TsOctet" 
objects, to be appended to the "TsOctets" object. The 
number of elements in the array must be greater than cr 
equal to the value of "size" . 
30 Note : For the case where "size" is zero, a zero length 

array must be provided by the caller. 
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ownership 

An enumeration specifying Che method by which the 

array of octets is to be incorporated into the "TsOctets" 

object. The possible values and their corresponding 

5 meanings are the same as those described for the "TsOctets 

(size_t size, TsOctet * data, CopyOwnership ownership) " 
function . 

nextSeg : 

const TsOctet * nextSeg (size_t & segSize) 

0 Returns either an array of octets and a size value or 

the NULL pointer. Over multiple invocations, the 
"nextSeg" function returns a collection of octet array 
segments which together, in order of appearance, convey 
the array of octets contained within zhe "TsOctets" 
5 object. Subsequent to the return of the last such segment 
and until the next invocation of the "reset" function, the 
"nextSeg" function returns the NULL pointer and leaves the 
value of the "segSize" parameter unchanged. 
Note: The total number of segments returned and size 

of each individual segment are implementation 
dependent . 

segSize 

A reference to an unsigned integer value to be 
updated with the size of the segment being returned. 

reset : 

void reset () 

Causes the next invocation the "nextSeg" function to 
return the first segment of octets contained within the 
"TsOctets" object. 

size : 
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size_t size 0 const 

Returns the total number of octets currently 
contained within the "TsOctets" object. 

7 . 12 TsPSTNMeans 
5 The "TsPSTNMeans " class provides a representation 

of the Telescript class " PSTNMeans" , as defined in Section 
3 of. this appendix. An implementation of the 
"TsPSTNMeans " class shall provide, at a minimum, the 
following functionality. 
10 class TsPSTNMeans : public TsReservableMeans { 

publ ic : 

TsPSTNMeans (const TsReservat ion & reservation, 

TsTelenumber * telenumber) ; 
-TsPSTNMeans ( } ; 
15 TsTelenumber * cetTelenumber () const; 

}; 



Cons true t ion 
30 TsPSTNMeans : 

TsPSTNMeans (const TsReservat ion & reservation, 
20 TsTelenumber * telenumber) 



50 



Constructs a new " TsPSTNMeans " object. 
reservat ion 

A reference to a "TsReservat ion" object that is to 
form the reservation value of the "TsReservableMeans" 
25 super-class component of the new " TsPSTNMeans " object. 

telenumber 

A pointer to a "TsTelenumber" object that is to form 
the telenumber value of the new "TsPSTNMeans" object. 

Destruction 
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-TsPSTNMeans : 
~Ts?5TNMeans {) 

Destroys the "TsFSTNMeans" object. The " TsPSTNMeans ' 
object and all data for which the object has ownership 
5 responsibility are destroyed. 

Data Access 

ge t Te 1 e numbe r : 

const TsTelenumber * get Tele number () const 



Returns a pointer to the telenumber value contained 
20 10 within the "TsPSTNMeans " object. 

7-13 TsReservableMeans 

The "TsReservableMeans" class, provides a C+ + 
representation of the Telescript class "ReservableMeans" , 
as defined in Section 3 of this appendix. An 
15 implementation of the "TsReservableMeans" class shall 
provide, at a minimum, the following functionality, 
class TsReservableMeans : public TsMeans 
( 

protected : 

35 20 TsReservableMeans (TsMeans :: Type type, 

const TsReservation & reservation) ; 
virtual -TsReservableMeans ()/ 
public : 

40 

TsReservation & getReservat ion () const; 

25 }; 

45 Construction 

TsReservableMeans : 

TsReservableMeans (TsMeans :: Type type, 

const TsReservation & reservation) 



30 



Constructs a new "TsReservableMeans" object. 
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An enumeration specifying the means type value of the 
"TsMeans" super-class component of the new 
"TsReservableMeans " object . 



A reference to a "TsReservation" object conveying the 
reservation value to be contained within the new 
"TsReservableMeans" object . 

Destruction 



virtual -TsReservableMeans {) 

Destroys the "TsReservableMeans" object. The 
"TsReservableMeans" object and all data for which the 
object has ownership responsibility are destroyed. 

5 Data Access 

cetReservat ion : 

const TsReservation & getReservation 0 const 

Returns a reference to the reservation value 
contained within the "TsReservableMeans" object. 

7 . 14 TsReservation 

The "TsReservation" class provides a C+ + 
representation of the Telescript class "Reservation", as 
defined in Section 3 of this appendix. An implementation 
of the "TsReservation" class shall provide, at a minimum, 
the following functionality. 



5 



reservation 



0 



-TsReservable -Means : 



class TsReservation 



public : 



TsReservation (Tslnteger id = 
-TsReservation {) ; 



0) ; 
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Tslnteger id 0 const; 

}; 

Construct ion 

TsReservat ion : 
5 TsReservaticn (Ts Integer id = 0) 

Constructs a new •'TsReservaticn" object. 

id 

A "Tslnteger" that is to form the reservation, 
identifier value of the new "TsReservation" object. 

.0 Destruction 

-TsReservaticn ; 
-TsReservation { ) 

Destroys the "TsReservation" object. The 
"TsReservation" object and all data for which the object 
5 has ownership responsibility are destroyed. 

Data Access 
id: 

Tslnteger id {) const 

Returns the reservation identifier value of the 
0 "TsReservation" object. 

7 . 15 TsString 

The TsString class provides a Ct+ representation of 
the Telescript class "String", as defined in Appendix A o1 
this disclosure. An implementation of the "TsString" 
5 class shall provide, at a minimum, the following 
functionality. 

Issue: This needs to be extended to support non-ASCII 
character sets. 
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class TsString 

{ 

public : 

TsString (const TsCharacter * string) ; 
-TsString ( ) ; 

const TsCharacter * getString () const; 
size_t size (i const; 

}; 



15 Construction 

10 TsString: 

TsString (const TsCharacter * string) 



10 
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Constructs a new "TsString" object 



string 

25 A pointer to a "TsCharacter" array, terminated by a 

15 null character, conveying the string of characters to be 
contained within the new "TsString" object. 



Destruction 

-TsString : 
-TsString ( ) 

20 Destroys the "TsString" object. The "TsString" 

object and all data for which the object has ownership 
responsibility are destroyed. 



Data Access 

getString : 

45 25 const TsCharacter * getString () const 

Returns a pointer to the string of characters 
contained within the "TsString" object. 

50 

size : 
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size_t size ( ) const 

Returns the number of characters currently contained 
within the "TsString" object. 

7.16 TsTeleaddress 

5 The "TsTeleaddress" class provides a C++- 

representation of the Telescript class "Teleaddress " , as 
defined in Appendix A of this- disclosure. An 
implementation of the "TsTeleaddress" class shall provide, 
at a minimum, the following functionality. 

0 class TsTeleaddress 

{ 

public: 

TsTeleaddress (TsOctets * provider, 

TsString * location) ; 
^TsTeleaddress (} ; 

const TsOctets * getProvider () const; 
const TsString * getLocat ion () const; 
const TsOctets * nextRoutingAdvice (); 
void reset ( ) ; 

int routingAdviceCount () const; 

void appendRoucingAdvice (TsOctets * advice) ; 

}; 

Construction 

TsTeleaddress : 

TsTeleaddress (TsOctets * provider, TsString * 
location) 

Constructs a new "TsTeleaddress" object. 

Subsequent to construction, the list of routing 
advice elements contained within the newly created 
teleaddress object will be empty. 
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provider 

Either a pointer to a "TsOctets" object that is to 
form the provider value of the new "TsTeleaddress" object 
or the NULL pointer if the new teleaddress object is to 
5 contain no provider value. 

location 

Either a pointer to a "TsString" object that is to 
form the location value of the new "TsTeleaddress " object 
or the NULL pointer if the new teleaddress object is to 
0 contain no location value. 



Destruction 

-TsTeleaddress : 
-TsTeleaddress () 



Destroys the "TsTeleaddress" object. The 
5 "TsTeleaddress" object and all data for which the object 
has wnership responsibility are destroyed. 

Data Access 

aooendRoutina-Advice : 

void appendRoutingAdvice (TsOctets * advice) 

Appends a single element of routing advice, in the 
form of a "TsOctets" object, to the list of routing advic 
contained within the "TsTeleaddress" object. 

advice 

A pointer to a "TsOctets" object conveying the 
routing advice element to be appended to the 
"TsTeleaddress" object's routing advice list. 

getProvider : 

const TsOctets * getProvider {) const 
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Returns either a pointer to the provider value of the 
"TsTeleaddress" object, or the NULL pointer if the 
" TsTeleaddress " object: contains no provider value. 



getLocation : 

const TsString * getLocation () const 



Returns either a pointer to the location value of the 
"TsTeleaddress" object, or the NULL pointer if the 
"TsTeleaddress" object contains no location value. 



next Routing Advice : 

const TsOctets * nextRcut ingAdvice {) 



Returns either a pointer to an element of routing 
advice, in the form of a "TsCctets" object, or the NULL 
pointer. Over multiple invocations, the 

" nextRcut ingAdvice 0 " function returns the set of routing 
advice elements contained within the "TsTeleaddress" 
object in the order of their containment. 

Subsequent to return of the last routing advice 
element and until the next invocation of the reset 
function, the "nextRout ingAdvice 0 " function returns the 
NULL pointer. 



reset : 

void reset () 



Causes the next invocation of the 
"nextRoutingAdvice {) " function to return the first element 
of routing advice contained within the "TsTeleaddress" 
ob j ect . 



rout ingAdvice -Count : 

size_t rout ingAdviceCount 0 const 
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Returns the number of elements of routing advice 
currently contained within the "TsTeleaddress " object. 



7 . 17 TsTelename 

The "TsTelename" class provides a C + -r representation 
5 of the Teiescript class "Telename " , as defined in Appendix 
A of this disclosure. An implementation of the 
"TsTelename" class shall provide, at a minimum, the 
following functionality, 
class TsTelename 
■o { 

publ ic : 

TsTelename (TsOctets * authority, TsOctets * 
identity); -TsTelename th- 

eorist TsOctets * getAuthority () const; 
5 const TsOctets * get Identity {) const; 

}; 



Construction 

TsTelename : 

TsTelename (TsOctets * authority, TsOctets * 
0 identity) 



Constructs a new "TsTelename" object. 
authority 

A pointer to an octet string that is to form the 
authority value of the new "TsTelename" object. 

5 identity 

Either a pointer to an octet scring that is to form 
the identity value of the new "TsTelename" object, or the 
NULL pointer if the "TsTelename" object is to contain no 
identity value. 
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Destruction 

-TsTelename : 
-TsTelename 0 

Destroys the "TsTelename" object. The '•TsTeiename 1 ' 
5 object and all data for which the object has ownership 
responsibility are destroyed. 

Data Access 

getAuthority : 

const TsOctets * getAuthority () const 

0 Returns a pointer to the authority value contained 

within the "TsTeiename** object. 

get Identity : 

const TsOctets * get Identity () const 

Returns either a pointer to the identity value 
5 contained within the "TsTeiename" object, or NULL if the 
■'TsTeiename" object contains no identity value. 

7 . 18 TsTelenumber 

The "TsTelenumber" class provides a C++ 
representation of the Telescript class "Telenumber " , as 
0 defined in Appendix A of this disclosure. An 

implementation of the "TsTelenumber" class shall provide, 
at a minimum, the following functionality, 
class TsTelenumber 

{ 

5 public: 

TsTelenumber {TsString * country, TsString * 
telephone, TsString * extension); 

-TsTelenumber {); 

const TsString * getCountry {} const; 
0 const TsString * getTeiephone 0 const; 
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const TsString * get Extension () const, 



Construct ion 

TsTelenumber : 
5 TsTelenumber {TsString * country, TsString + 

telephone, TsString * extension) 



Constructs a new "TsTelenumber" object. 



country 

Either a pointer to a "TsString" object that is to 
0 form the country code value of new "TsTelenumber" object, 
or the NULL pointer if the "TsTelenumber" object is to 
contain no country code value. 

Note : The value contained within the provided 

"TsString" object is restricted to the set 
5 of numerical codes that CCITT assigns to 

countries or other geographical areas. 

telephone 

Either a pointer to a "TsString" object that is to 
form the telephone number value of the new "TsTelenumber" 
0 object, or the NULL pointer if the "TsTelenumber" object 
is to contain no telephone number value. 
Note: The characters that form the value contained 

within the provided "TsString" object are 
restricted to the numerals ( ,, 0 H -"9 n ), the hyphen 
5 character ( " - " ) and the space character { " "). 

extension 

Either a pointer to a "TsString" object that is to 
form the extension number value of the new "TsTelenumber" 
object, or the NULL pointer if the "TsTelenumber" object 
0 is to contain no extension number value. 
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Note : The characters that form the value contained 

within the provided "TsString" object are 
restricted to the numerals ("0"-"9 m ;, the hyphen 
character ("-"} and the space character (" "). 

5 Destruction 

-TsTelenumber : 
-TsTelenumber { ) 

Destroys the "TsTelenumber" object. The 
"TsTelenumber" object and all data for which the object 
.0 has ownership responsibility are destroyed. 

Data Access 

getCountry: 

const TsString * getCountry () const 

Returns either a pointer to the country code value cf 
5 the "TsTeleaddress" object, or the NULL pointer if the 
"TsTeleaddress" object contains no country code value. 

getTelephone : 

const TsString + getTelephone () const 

Returns either a pointer to the telephone number 
0 value of the "TsTeleaddress" object, or the NULL pointer 
if the "TsTeleaddress" object contains no telephone number 
value . 

aetExtension : 

const TsString * getExtension {) const 
5 Returns either a pointer to the extension number 

value of the "TsTeleaddress" object, or the NULL pointer 
if the "TsTeleaddress" object contains no extension number 
value . 



496 



EP 0 634 719 A2 



7 . 19 TsWav 

The "TsWay" class provides a C+ + representation of 
the Telescript class "Way", as defined in Appendix A of 
this disclosure. An implementation of the "TsWay" class 
shall provide, at a minimum, the following functionality. 

class TsWay 

{ 

public : 

TsWay (TsTelename * name, 

TsMeans * means, 

TsObj Specif ier * secRegimeld) ; 
-TsWay ( ) ; 

const TsTelename * getName 0 const; 

const TsMeans * getMeans () const; 

const TsObjSpecif ier * getSecRegimeld {) const; 



Construction 
TsWav: 

TsWay (TsTelename * name, 
TsMeans * means , 
TsObjSpecif ier * secRegimeld) 

Constructs a new "TsWay" object. 

name 

Either a pointer to a "TsTelename" object that is to 
form the engine/region ceiename value of the new "TsWay" 
object, or the NULL pointier if the new "TsWay" object is 
to contain no engine/region telename. 

means 

Either a pointer to a "TsMeans" object that is to 
form the means value of the r.ew "TsWay" object, or the 
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NULL pointer if the new "TsWay" object is to contain no 
means value . 

secReqimeld 

Either a pointer to a "TsObj Specif ier" object that is 
5 to form the security regime identifier value of the new 
"TsWay" object, or the NULL pointer if the new "TsWay" 
object is to contain no security regime identifier value. 

Destruction 
-TsWay: 
0 -TsWay () 

Destroys the "TsWay" object. The "TsWay" object and 
all data for which the object has ownership responsibility 
are destroyed. 

Data Access 
5 getName : 

const TsTelename * getName () const 

Returns either a pointer to the engine/region 
telename value contained within the "TsWay" object, or the 
NULL pointer if the "TsWay" object contains no 
0 engine/region telename. 

qetMeans : 

const TsMeans * getMeans 0 const 

Returns either a pointer to the means value contained 
within the TsWay object, or the NULL pointer if the 
5 "TsWay" object contains no means value. 

getSecRegimeld: 

const TsObjSpecif ier * getSecRegimeld () const 
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Returns either a pointer to the security regime 
identifier value contained within the "TsWay" object or 
the NULL pointer if the "TsWay" contains no security 
regime identifier value. 
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APPENDIX D 

Copyright ® General Magic, Inc. 1993. All Rights 
Reserved . 

The following table of contents is to assist the 
reader in understanding the organization of and locating 
information within this appendix. 
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4 . 4 Shipping Box 

4.5 Traveled 

I INTRODUCTION 

This appendix describes a mechanism for 
5 place-to-place transfer, broadly construed to include 
object interchange and purgatory. 

This appendix is organized in the manner of Appendix 
A of this disclosure. 

The place-to-place transfer mechanism necessitates 
.0 several other changes and additions to the Instruction Sei 
of Appendix A, which are described in the subsections 
below . 

1 . 1 Permit Chances 

Whether "go'* or operation "send" succeeds or fails, 
5 allow operation "entering" to grant an agent an initial 
local permit more permissive than the one the agent 
requested . 

Provided operation go or operation "send" fails, 
allow operation "entering" to admit an agent while 

0 granting it an initial local permit less permissive than 
the one the agent requested. 

Add to class "Process" a read-only public instance 
attribute, " regionalPermi t " , which is the permit the 
current region grants a process. 

5 Replace the "terminate" operation of a place with a 

new, "changePermit " operation which replaces a process' 
local permit. The operation is performed at the request 
of either the place itself or a peer of the process in 
question. 

0 Add to class "Process" a system instance operation, 

"permitChanged" , which the Engine requests whenever a 
place changes an occupant's local permit, e.g., as 
operation "entering" does above, or to eject the occupant 
with or without a grace period. 
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permit: Changed : 

op () Permi t Changed ! Nil ; 



Requested whenever the responder's local permit is 
changed e.g., by the place the responder is entering or 
5 occupies already, either to add capabilities or to remove 
them. If the operation's result is an exception, rather 
than a nil, the Engine throws the exception in the 
responder's thread of execution. 

The method for this operation that is native to class 
0 "Process" simply returns a nil. 

Add to class "Execution Exception" a subclass, 
"PermitChanged" , the throwing of which signifies that the 
current process' local permit has been changed. 

PermitChanoed : 
5 interface (Execut ionExcept ion) = (); 



A process' ability tc catch and recover from 
this exception, when the process' new local 
permit is severely restrictive, are limited by 
the rules of process termination. 



C 1 . 2 Other Changes 

Provided operation "go" or operation "send" fails, 
allow an agent to find one or more of its interchanged 
objects missing, as described in the place-to-place 
transfer model. 

5 Allow the "go" or "send" operation to take an agent 

to its destination even if the operation fails, e.g., 
because the destination will not grant the agent the 
permit the agent requested. Furthermore, operation 
"entering" is involved even in this case. 

0 Let the Engine request any feature, predefined or 

user-defined, not just a system feature. A user-defined 
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method for a feature requested by the Engine finds client 
and process to be nils, as if the feature were a system 
feature . 

Add to class "Process" a read-only public instance 
5 attribute, "authenticity", which documents the degree of 
confidence the current region has in a process' purported 
authority. This attribute is defined in § 4 . 57 of 
Appendix A. 

To class "Process" add a read-only public instance 
0 attribute, "creationTime " , which is the time at which a 
process was created. 

Discard the "brand" attribute of a process. 
Note ; Instead a region can define a subclass of class 

"Permit" and supply an instance thereof as .a 
5 process' " regicnaiPermit " attribute. 

2 TELESCRIPT CONCEPTS 

2 . 1 Place-to-place Transfer Model 

The Instruction Set realizes the "place-to-place 
transfer model" this section defines. 

0 2.1.1 Traveled Places 

A "traveled" place is one through which shipping 
boxes are transferred. 

Transfer 

The traveled places to which the Network -entrusts a 
certain shipping box cooperate to "transfer" the box's 
contents from one place, the "origin" of the shipping box, 
to one cr more places, "destinations" of the shipping box. 
A traveled place creates new shipping boxes whenever it 
must transfer the contents of a shipping box in different 
directions . 

The transfer of the contents of a shipping box from 
its origin to any one of its destinations proceeds in four 
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steps, the last two of which, i.e. transfer in and 
transfer out, can be repeated within a single transfer. 

Submission 

A transfer begins with a shipping box's "submission"; 
The traveled place to which the shipping box is first 
transferred in as a consequence is its "source". 

Delivery 

A transfer ends with a shipping box's "delivery". 
The places to which a submitted shipping box is to be 
delivered are its "dest inat icns " . 

A shipping box's delivery is either "normal" or 
"abnormal". In the first case, the shipping box's 
destinations are as specified at submission, and all 
critical parts of the shipping box's contents are present.. 
In the second case, the Network may have prescribed 
alternative destinations for the shipping box, and some 
critical parts of the shipping box's contents may be 
absent. An exception explains the abnormality. 

Transfer In 

A shipping box is "transferred in" to a traveled 
place. The transfer in is a consequence of either the 
shipping box's submission from a place, traveled or 
otherwise, or the shipping box's transfer out from a 
traveled place, different from or the same as the traveled 
place to which the shipping box is transferred in. The 
place from which the shipping box comes is the shipping 
box's "previous hop". 

Transfer Out 

A shipping box is "transferred cut" from a traveled 
place. The transfer out has as its consequence either the 
shipping box's transfer in to a traveled place, different 
from or the same as the traveled place from which the 
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shipping box is transferred out, or the shipping box's 
delivery to places, traveled or otherwise. The place or 
places to which the shipping box goes is the shipping 
box's "next hop". 

5 2.1.2 Shipping 3oxes 

A "shipping box" is one object that holds another, 
its "contents", and that can be used to transfer chat 
object from place to place. 

Peek 

LO A traveled place can "peek" ac the object that is a 

shipping box's concents, i.e., can gee the object's 
attributes, subject to the limitation below. 

A shipping box gets an attribute of the shipping 
box's contents using a protected reference :o the 

.5 contents. If a user-defined method is involved, the 
method finds "client", "here", and "process" to be nils, 
as if the attribute were a system attribute. 
Additionally, peeking at an attribute disregards its 
prescribed passage, in every case returning a copy of the 

0 attribute, rather than the original. 

Poke 

A traveled place can "poke" at the object that is a 
shipping box's contents, i.e., can set the object's 
attributes, subject to the limitation below. A traveled 

5 place can do this, however, only if the traveled place is 
suitably privileged. 

A shipping box sets an attribute of the shipping 
box's contents using an unprotected reference to the 
contents. If a user-defined method is involved, the 

0 method finds "client", "here", and "process" to be nils, 
as if the attribute were a system attribute. 
Additionally, poking at an attribute disregards its 
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prescribed passage, in every case using a copy of the 
proposed attribute, rather than the original. 

The privileges alluded to above are assigned as 
follows. An engine place can set the 
5 "authenticationState" or " regionalPermit " attribute, even 
though the Instruction Set defines these attributes as 
read-only. Preemptive settings of the "regionalPermit" 
attribute can dictate the shipping box's abnormal 
del i very . 

15 10 Note : A traveled place cannot request operations of a 

shipping box's contents. 



w 
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25 



Rebox 

A traveled place can "rebox" a shipping box, which 
the traveled place does if the shipping box must be 
15 transferred in different directions. The Engine removes 
specified destination tickets from the shipping box, 
replaces them with nils, and reaffixes them to a new 
shipping box identical in content to the existing one. 

50 Redirect: 

20 A traveled place can "redirect" a shipping box, which 

the traveled place does if an exception arises during its 
transfer. The Engine affixes the exception to the 
shipping box, removes any nils among the shipping box's 
destination tickets, and can substitute for each remaining 
25 destination ticket a single specified ticket. 
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2.1.3 Opened Objects 

An "opened" object is one whose zero or more parts 
can be manipulated. 

Parts 

30 Each "part" of an object, opened or not, is an 

interchanged object whose digest is net a nil. A part of 
an opened object can be replaced with another object of 
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the part's class and digest without materially affecting 
the opened object. 

Presence 

Each part of an object, opened or not is either 
5 "present" or absent. The "absence" of a part, in general, 
limits the object's use, but makes the object's 
place-to-place transfer more efficient. If an object 
attempts to use a reference to a cart of itself that is 
absent at the time, the Engine throws "Reference Void". 
0 Note : In typical practice, a part of the contents of a 

shipping box is present at the shipping box's 
submission and again at the shipping box's 
delivery, but is absent at some or all cf the 
other steps in the shipping box's transfer, as a 
5 performance optimization. 

Criticality 

Each part of an object, opened or not, is either 
critical or non-critical. An object is designed to be 
used even in the absence of one or more of the object's 
0 "non-critical" parts, but not in the absence of any of the 
object's "critical" cnes . 

Note: The absence of a critical part of an object 

prevents normal delivery cf a shipping box 
containing that object, while the absence of a 
5 non-critical part does not. 

Njote; In typical practice, all parts of an object are 

critical everywhere . Occasionally, a part of an 
object is critical only while the object is in a 
certain place . 

0 2.1.4 Opened Shipping Boxes 

An "opened shipping box" is one whose parts can be 
manipulated. The parts of an opened shipping box are 
those of the shipping box's contents. 
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2.1.5 Parts Boxes 

A "parts box" is an opened object whose parts can be 
specified explicitly and arbitrarily. Parts boxes serve 
the following four purposes. 

5 Manipulating Parts 

The parts of an opened object are manipulated by 
means of parts boxes. This ensures that the parts are not 
directly accessible to the object doing the manipulation. 
The parts in a parts box, e.g., can be included in an 
10 opened object, and specified parts of an opened object can 
be copied or moved into a parts box. The parts themselves 
cannot be examined, even while in the parts box. 
Note: This protects the intellectual property 

represented by interchanged objects. 

15 Storing Parts 

A traveled place entrusted with opened shipping boxes 
can use a parts box as a repository for parts to be 
included in such shipping boxes. The parts box, a small 
database, serves as a resource in place-to-place transfer. 
20 Note : This simplifies the implementation of traveled 

places . 



Taking Parts 

If a shipping box's contents include a parts box, the 
parts box's critical parts are specifically excluded from 
25 the shipping box's par. j. Thus the traveled places 
involved in the shipping box's transfer can neither 
examine nor exclude those parts. The optimization that 
such exclusion would represent is not attempted. 
45 Note: This enables agents that support place-to-place 

30 transfer to move interchanged objects between 

traveled places without the system as a whole 
attempting to avoid that movement by the 
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system's (in this case misguided) optimization 
efforts. 

Leaving Farts 

If a shipping box's contents include a parts box, the 
5 part box's non-cricicai parts are specifically included in 
the shipping box's. In this way, an agent can declare an 
interchanged object non-critical and thereafter take trips 
without that part of necessity accompanying the agent. By 
later removing the part frcm the parts box, the agent 
0 declares the part critical. Then, if the part is absent, 
either the Engine finds the part locally, or the Engine 
throws "Reference Void" when the agent uses the part. 
Note : This enables agents to visit places at which 

certain cf their interchanged objects will net 
5 be used without insisting that those objects 

nevertheless be present there. 

2.1.6 The Use of Tickets 

Tickets define, as detailed below, the places through 
which a shipping box is transferred. Throughout this 
0 section, the "place attributes" are the "desc inat ionName " , 
"destinationAddress" , and "dest inat ionClass " attributes. 
Other ticket attributes that are not mentioned 
specifically below are disregarded. 

Source 

5 A ticket is used to define a shipping box's source. 

The ticket's place attributes, which identify the source, 
are an assigned telename, an assigned teleaddress, and an 
assigned citation, respectively. The ticket's "way" 
attribute, if not a nil, diccates the way in which the 

0 source shall be reached if need be. 

Destination 
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A ticket is used :o define each of a shipping box's 
destinations. The ticket's place attributes identify the 
destination in question. The ticket's "way" attribute, if 
not a nil, dictates the way in which that destination 
5 shall be reached. The "desiredWait " and "maximumWait " 
attributes give the quality of service to be provided the 
shipping box as it is transferred to that destination. 

Previous Hop 

A ticket is used to define a shipping box's previous 
.0 hop. The ticket's attributes "dest inat ionName " , 
"destinationAddress" and "destinationClass " , which 
identify the previous hop, are an assigned telename, an 
assigned teleaddress, and an assigned citation, 
respectively. The ticket's "way" attribute, if not a nil. 
5 defines the way in which, the shipping box was transferred 
in from the previous hoc. 

Next Hop 

A ticket is used to define a shipping box's next hop. 
The ticket's place attributes identify the next hop. The 
0 ticket's "way" attribute, if not a nil, dictates the way 
in which the next hop shall be reached. 

2.1.7 The Engine's Role 

Traveled places are properly viewed as facilitating, 
rather than controlling, the transfer of shipping boxes 
5 and their eventual delivery to their destinations. The 
Engine itself is instrumental in this process as follows. 

Transfer In 

Whenever a traveled place transfers in a shipping 
box, the Engine has already determined whether that 
D shipping box is an opened one or not. In typical 
practice, the Engine makes this determination 
consistently, not on a box- by-box basis. Thus some 
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traveled places, in general, are entrusted with the 
interchange of parts of the contents of shipping boxes, 
while others are not. 

Transfer Out 

5 Whenever a traveled place transfers out a shipping 

box, "A", the Engine does the following. First, the 
Engine reboxes "A", moving to a new shipping box, "B", the 
tickets to any destinations to which the Engine can 
deliver shipping boxes. The Engine moves tickets to " B " , 

0 however, only if the transfer out is one allowing. 

delivery. Second, the Engine reboxes "A" again, moving 
all remaining tickets to another new shipping box, "C" . 
Third, the Engine asynchronously transfers "C" and 
attempts to deliver "B". 

5 Exoirat ion 

Whenever a traveled place allows any destination 
tickets of a shipping box, "A", to expire, the Engine does 
the following. Such a ticket "expires" when its maximum 
duration is reached. First, the Engine reboxes "A", 

0 moving the expired tickets to a new shipping box, "B" . 
Second, the Engine redirects "3 M to a place chosen by the 
Engine, recording "Ticket Expired" as the cause of the 
abnormality. Third, the Engine transfers out "B" to a 
place chosen by the Engine, as if the traveled place had 

5 done so . 

Discard 

Whenever a traveled place discards a shipping box, 
"A", to which any destination tickets remain affixed, and 
so as to provoke the finalization of "A" , the Engine does 
0 the following. First, the Engine reboxes "A", moving all 
destination tickets to a new shipping box, "B" . Second, 
the Engine destroys "A". Third, the Engine asynchronously 



511 



EP 0 634 719 A2 



transfers out "B" to a place of the Engine's own choosing, 
as if the traveled place had done so. 

2.1.3 The Engine's Rcle in Routing 

The Engine limits the routes along which a shipping 
5 box is transferred by selecting the shipping box's second 
hop, constraining the shipping box's second- to- last hop, 
and, furthermore, restricting the shipping box's first hop 
in any sequence of hops within a region. 

First Regional Hod 
0 The Engines of a region cooperate to ensure that a 

shipping box entering the region is transferred in at an 
engine place before the shipping box is either transferred 
in at another traveled place in the region or delivered 
within the region. 

5 Second Hep 

The Engine selects as follows a shipping box's second 
hop, i.e., the traveled place at which the shipping box is 
first transferred in - - from the shipping box's source. 

The second hop is either the shipping box's 
0 submission place, if that is a traveled place, or a 

superplace of the submission place, otherwise. If several 
superplaces are traveled places, the one enclosing none of 
the others is selected. 

Note: Thus "submission" can be visualized as causing a 

5 shipping box to fall through its origin and 

successive superplaces until the shipping box 
reaches a traveled place. 

Second- to- last Hop 

The Engine constrains as follows a shipping box's 
0 second-to-last hop, i.e., the traveled place from which 
the shipping box is last transferred out to all of the 
shipping box's destinations. 
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The second- to-last hop is either a destination itsel 
or one of its superplaces, this being so for each of the 
shipping box's destinations individually. 
Note: Thus "delivery" can be visualized as causing a 

5 shipping box to rise through successive 

subplaces until the shipping box reaches one 
qualifying as each destination of the shipping 
box . 

Given the second- to- last hop, if several places 
10 qualify as one of the shipping box's destinations, the 
Engine tries to deliver the shipping box to one of them, 
approaching them in the order defined by section 2.5.4 cf 
Appendix A. 

Given the second- to - last hop, if either no places 
15 qualify as one of the shipping box's destinations or none 
of them accepts delivery of the shipping cox, the Engine 
transfers out the shipping box to a place of the Engine's 
own choosing. 

Non -delivery 

0 An Engine treats the ultimate undel i verabil ity of a 

shipping box as a system error, which the Engine handles 
in accordance with the 0A.M policy in force. 
Note: An Engine can provide a place of last resort, 

"Purgatory", for otherwise undeliverable 
S shipping boxes. S\.::h a place can severely limit 

an occupant's local permit. 

2,1.9 Implementing Go 

The method for "go" native to class "Agent" 
implements the operation as follows using a shipping box 
0 whose contents are the agent and the objects the agent 
owns . 

Submission 
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The Engine creates and submits a shipping box 
containing the agent after validating the agent's request 
for the operation. Thus the shipping box's first hop, 
i.e., its origin, is the place the agent occupies when the 
5 agent requests the operation. 

Delivery 

The Engine delivers a shipping box by completing the 
operation. Thus the shipping box's last hop, i.e., its 
sole destination, is the place the agent occupies when the 

0 agent completes the operation. 

The operation either succeeds, if both the shipping 
box does not record an exception and only non-critical 
parts of the shipping box's contents are absent, or fails, 
otherwise. If the operation fails, the operation throws 

5 either the exception the shipping box records, if che 
shipping box records one, or an exception of the Engine's 
choosing, otherwise . 

2.1.10 Implementing Send 

The method for operation "send" native to class 

0 "Agent" implements that operation in the same way as 
operation "go" is implemented, with two differences. 
First, the shipping box has as many destinations as there 
are clones to be transferred. Second, the contents of the 
shipping box are a representative clone of the agent 

5 requesting the operation. The "identity" attribute of the 
clone's assigned telename is a nil at submission, but is 
set distinctively as each clone is delivered. 

i TELESCRIPT CLASS OVERVIEWS 

3 - 1 Place-t o-place Transfer Group 
0 Object (Referenced) 

• £arts_Bo_2c_ (Opened) 

• Shipping Box (Unmovprn 
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• • Opened Shipping 3ox (Opened) 

Opened 

Traveled 

3.1.1 Opened 
5 Ooerat ions 

clearParts 

examineParts 

excludeParts 

getClasses 
0 getDigests 

get Number 

includeParts 

An "opened" object is one whose parts can be 
manipulated. 

5 An opened object's native operations reveal the 

number (operation "getNumber " ) , classes (operation 
"getClasses"), and digests (operation "getDigests " ) of 
parts satisfying specified criteria; include new parts 
(operation "includeParts"); exclude existing parts 

0 (operation "excludeParts"); exclude all existing parts 
satisfying a specified criterion (operation "clearParts" 
and arrange for the inspection of specified parts 
(operation "examineParts") . 

3.1.2 Opened Shipping Roy 

5 An "opened shipping box" is one whose parts can be 

manipulated . 

3.1.3 Parts Box 
Operations 

includeParts 

3 A "parts box" is an object whose parts can be both 

specified and manipulated. 
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A parts box's native operation includes new parts 
(operation " includeParts " ) . 

3.1.4 Shipping Box 

Attributes 
5 destinations 

exception 

source 

t irae 
Operations 
C peek 

poke 

rebox 

redirect 

A "shipping box" is an object that can be transferred 
5 between places. 

A shipping box's native attributes are the time the 
shipping box was submitted (attribute "time"), a ticket to 
the shipping box's source (attribute "source") , tickets to 
the shipping box's destinations (attribute 
0 "destinations" ) , and any exception encountered in 

transferring the shipping box (attribute "exception") . 

A shipping box's native operations get (operation 
"peek") or set (operation "poke") a specified attribute of 
the shipping box's contents, redirect the shipping box in 
5 case of an exception (operation "redirect"), and rebox the 
shipping box to permit several next hops (operation 
" rebox" ) . 

3.1.5 Traveled 
Operations 
0 transf erOut 

transferredln 
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A "-raveled" object is a place that can transfer 
shipping boxes. 

A traveled place's native operations transfer out a 
shipping box (operation " t ransf erOut " ) and act upon a 
shipping box's transfer in (operation " t ransf erredln" ) . 

4 TELESCRIPT CLASS DETAILS 

4 . 1 Opened 
Opened 

Class 

Opened : 

sealed abstract interface {) = (...); 

Public Instance Coeraticns 
clearParts : 

unprotected op (isCritical: Boolean j Nil ) ; 

Removes from the responder and discards all of the 
responder's present parts that satisfy the criterion that 
the boolean (argument "isCritical") prescribes. See 
operation "getClasses" below. 

examineParts : 

op ( of Class : Class; 

digests: protected Set [Object]) 

PartsBox j Nil ; 

Leaves in the responder and returns the present parts 
whose class (argument "cfclass") and digests (argument 
"digests") are specified. The operation returns either a 
parts box comprising the parts, if there are any, or a 
nil, otherwise. 

excludeParts : 



517 



EP 0 634 719 A2 



unprotected op (of Class: Class; 

digests: protected Sec [Object]) 
PartsBox j Nil ; 

Excludes from the responder and returns the present 
5 parts whose class (argument "of Class" ) and digests 

(argument "digests") are specified. The operation returns 
either a parts box comprising the parts, if there are any, 
or a nil, otherwise. 

getClasses : 

0 op (isPresent, isCritical: BooleanjNii) 

protected Set [Class] ; 

Returns the classes of the parts of the responder 
that satisfy the criteria defined below that the 
booleans (arguments "isPresent" and "isCritical") 
5 prescribe. 

The first criterion, defined by the first boolean, is 
that the part is either present, if the boolean is true; 
absent, if it is false; or either, if the argument is a 
nil. The second criterion, defined by the second boolean, 
0 is that the part is either critical, if the boolean is 
true; non-critical, if it is false; or either, if the 
argument is a nil. 

getDiaests : 

op (ofClass: Class; isPresent, isCritical: 
5 Boolean | Nil) 

protected Set [Object] ; 

Returns the digests of the parts of the responder 
that are of the specified class (argument "of Class") and 
that satisfy the criteria see operation "getClasses" 
0 above -- that the booleans (argument "isPresent" and 
" isCritical" ) prescribe . 
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get Number : 

op (isPresent, isCritical: Boolean | Nil ) Integers- 
Returns the number of parts of the respcnder that 
satisfy the criteria see operation "getClasses" above - 
5 -that the booleans ( " isPresent " and "isCritical") 
prescribe . 

includeParts : 

unprotected op (parts: protected PartsBox); 

Includes in the responder the parts of the parts box 
10 (argument "parts") that match, in class and digest, parts 
of the responder. The operation first excludes frcm the 
responder and discards any matching parts that are present 
there already. 



4 . 2 Opened Shipping Box 
15 Object (Referenced) 

• Shipping Box (Unmoved) 

• • Ooened Shipping Box (Opened) 

Class 

OpenedShippinaBox : 
20 sealed interface (ShippingBox, Opened) = { ) ; 



50 



4 . 3 Parts Box 

Object (Referenced) 

• Parts Box (Opened) 

Class 
25 PartsBox : 

sealed interface (Object, Opened) = (...); 
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Construction 

initialize : 

5 

unprotected op ( 

criticalParts, noncrit icalParts : Set 
5 [Interchanged] [Nil) / 

10 

Makes the two sets of interchanged objects the 

responder's critical (argument "criticalParts") and 

non-critical (argument "noncriticalParts" ) parts, all ' 
15 . . , _ . 

present initially. If a nil is present instead of a set, 

10 however, the set is presumed cleared. 



20 Public Instance Operations 

" includeParts' 1 : 

unprotected op (parts: protected PartsBox) ; 

25 

Includes in the responder the parts of the parts box 
15 (argument "parts"). Each part is considered present in 
the responder; each part is considered critical in the 
30 responder iff the part is so considered in the parts bcx. 

The operation first excludes from the responder and 
discards any matching parts that are present there 
20 already. 

35 



4 . 4 Shipping Box 

Object (Referenced) 

• Shipping Box (Unmoved; 

Class 

2 5 ShippingBox : 

sealed interface (Object, Unmoved) , = (...); 

Construction 

ini t ial ize : 
unprotected cp () 
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throws FeatureUnavailable; 

Throws an exception ("FeatureUnavailable"). 
Note : A shipping box is created by means of operation 

M go" or "send", not using operation "new". 



5 Public Instance Attributes 
destinations : 

75 readonly protected List [Ticket j Ni 1 ] ; 



The tickets that define the responder's destinations, 
and zero or more nils, which replace tickets moved to 
10 other shipping boxes using operation "rebcx". 



exception : 

readonly TripExcept ion j Nil ; 

Either the trip exception encountered in the course 
of transferring the responder, if indeed a trip exception 
15 was encountered, or a nil, otherwise. 

source : 

readonly protected Ticket; 

The ticket that defines the responder's scarce. 
t ime : 

20 readonly Time ; 

The time at which the responder was submitted. 



Public Instance Operations 
peek : 

op (identifier: Identifier!) copied Object 
50 25 throws CopyUnavailable , FeatureUnavailable; 
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Returns the attribute of the responder's contents 
that the identifier (argument "identifier") denotes. 

An exception is thrown if the identifier denotes no 
attribute of the responded s contents that is accessible 
5 to the requester ( '» FeatureUnavailable " ) or a copy of the 
attribute is unavailable { "CopyUnavailable" > . 

poke : 

unprotected op (identifier: Identifier!; 
attribute: copied Object) 
0 throws Arcumentlnvalid, AttributeReadOnly , 

FeatureUnavai lable ; 

Makes the object {argument "attribute") the attribute 
of the responder's contents that the identifier (argument 
"identifier") denotes. The operation first discards the 
5 attribute if it exists. 

An exception is thrown if the object violates the 
attribute's constraint { "Argument Invalid" ) , the attribute 
is read-only ("AttributeReadOnly"), or the identifier 
denotes no attribute of the responder's contents that is 
0 accessible to the requester ("FeatureUnavailable"). 

rebox : 

unprotected op (tickets: protected Set [Integer]) 

ShippingBox 
throws Positionlnvaiid; 

5 Creates and returns a new shipping box whose contents 

are the same as the responder's, and moves to the new- 
shipping box the tickets at the specified positions 
("tickets") in the responder's "destinations" attribute, 
replacing them with ni 1 s . 

3 An exception is thrown if an asserted position is 

invalid as such ("Positionlnvaiid"). 
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redirect : 

unprotected op (exception: TripExcept ion; 
newDestinat ion : copied TicketjNil); 

Excludes from the responder's "destinations" 
5 attribute each nil item, replaces each item that remains 
with the ticket (argument "newDes t ination" ) iff there is 
one, and makes the exception (argument "exception") the 
responder's "exception" attribute. 

Adaptations 
0 copy 

Throws Copy Unavailable. 

finalize 

Reboxes the responder as defined by the Model . 

4 . 5 Traveled ' 
5 Traveled 

Class 

Traveled : 

abstract interface () = (...); 

Private Instance Operations 
0 transf erOut : 

unprotected op (shippingBox : unprotected Shipping3ox 
suggestedNextHop : protected 
Ticket j Nil ; 
canDeliver: 3oolean) ; 

5 Transfers out the shipping box (argument 

"shippingBox") to the place either defined by the ticket 
(argument "suggestedNextHop"}, if not a nil, or selected 
by the Engine, otherwise. Even if the ticket is present, 
the ticket suggests, rather than demands, that the next 
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hop be the place that the ticket defines. The boolean 
(argument " canDeliver " ) indicates whether the Engine is 
free to deliver the shipping box if the Engine is able to 
do so . 

5 System Instance Operations 
transf erredln : 

abstract unprotected cp (shippingBox : unprotected 
ShippingBox; 

previousKop : protected Ticket); 

10 Requested as the shipping box (argument 

"shippingBox") is transferred in from the place defined by 
che ticket (argument "previcusHop" ) . 



The computer program in Appendix G was compiled and 
linked, in one embodiment, using the UNIX operating system 

15 IRIX 4.0.5, the compiler, and the linker that are provided 
with a workstation such as the Iris Indigo® computer 
system available frcm Silicon Graphics of Mountain View, 
California. In a second exbodiment, the computer program 
in Appendix G was compiled using the MPW C++ compiler, and 

2 0 was linked using the MPW linker, both of which are 
available frcm Apple Computer, Inc. of Cupertino, 
California and which can be used on an Apple Macintosh® 
computer, which is also available from Apple Computer, 
Inc. The particular computer language and the computer 

25 system used are not an essential aspect of this invention. 
In view of this disclosure, those skilled in the art can 
implement the invention using a different computer 
language and/or a different computer system. 



Claims 



1. A method for implementing remote programming in a computer network comprising the steps of: 

defining a plurality of object-oriented classes including an agent class and a place class; 
forming instructions for a computer process, said instructions including said object-oriented 
classes, subclasses of said object-oriented classes, and a go operation; and 
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interpreting said instructions on a processor in said computer network wherein, in response 
to said go operation, an agent process is transported to a place process and further wherein said agent 
process is a member of said agent class and said place process is a member of said place class. 

5 2. The method for implementing remote programming in a computer network as in Claim 1 further comprising 
forming said go operation within said agent process. 

3. The method for implementing remote programming in a computer network as in Claim 1 further compris- 
ing: 

defining a class of class objects; 

forming a class object, wherein said class object (i) is a member of said class of class objects, 
and (ii) defines a first class which is a subclass of a selected one of said object-oriented classes; and 

forming an object, said object being a member of said first class; 

wherein said agent process owns said object; and transportation of said agent proc- 
ess to said place process comprises transporting said object and said class object to said place process. 

4. A method for implementing remote programming in a computer network comprising the steps of: 

defining a plurality of object-oriented classes including an agent class and a place class; 

forming instructions for a computer process including said object-oriented classes, sub- 
classes of said object-oriented classes, and a send operation; and 
20 ' interpreting said instructions on a processor in said computer network wherein, in response 

to said send operation, a clone of an agent process is transported to a place process and further wherein 
said clone and said agent process are each a member of said agent class and said place process is a 
member of said place class. 

25 5. The method for implementing remote programming in a computer network as in Claim 4 further comprising 
forming said send operation within said agent process. 

6. The method for implementing remote programming in a computer network as in Claim 1 , 2, 4 or 5 further 
comprising forming a subplace of said place wherein said subplace is a member of said place class and 

30 said place is a superplace of said subplace. 

7. The method for implementing remote programming in a computer network as in any one of Claims 1, 2 
or 4 to 6 further comprising designating said agent process as an owner of an object. 

35 8. The method for implementing remote programming in a computer network as in Claim 7 wherein trans- 
portation of said clone comprises transporting a copy of said object to said place process. 

9. The method for implementing remote programming in a computer network as in Claim 7 or 8 further com- 
prising forming within said object a digest. 

40 

1 0. The method for implementing remote programming in a computer network as in Claim 9 further comprising 
interchanging for said first-mentioned object a second object at said place process wherein said second 
object has a second digest equivalent to said first-mentioned digest and further wherein said first object 
is not transported to said place process. 

45 11. The method for implementing remote programming in a computer network as in Claim 8 or 9 when ap- 
pended to claim 4, 5 or 6 further comprising interchanging for said copy a second object, which is different 
from said first-mentioned object, at said place process wherein said second object has a second digest 
equivalent to said first-mentioned digest and further wherein said copy is not transported to said place 
process. 

50 

12. The method for implementing remote programming in a computer network as in any one of Claims 1 to 
11 further comprising specifying said place process by a ticket means. 

13. The method for implementing remote programming in a computer network as in Claim 12 further com- 
55 prising forming said ticket means within said agent process. 

14. The method for implementing remote programming in a computer network as in Claim 12 or 13 further 
comprising forming within said ticket means an address of said place process. 
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15. The method for implementing remote programming in a computer network as in Claim 14 wherein said 
address is a teleaddress 

16. The method for implementing remote programming in a computer network as in any one of Claims 12 to 
15 further comprising forming within said ticket means a name of said place process. 

17. The method for implementing remote programming in a computer network as in Claim 16 wherein said 
name is a telename. 

18. The method for implementing remote programming in a computer network as in Claim 4 further wherein, 
in response to said send operation, a second clone of said agent process is transported to a second place 
process wherein said second clone is a member of said agent class and is distinct from said first- 
mentioned clone and further wherein said second place process is a member of said place class. 

19. The method for implementing remote programming in a computer network as in Claim 18 further com- 
prising: 

determining that transportation of said first clone to said first place process and of said sec- 
ond clone to said second place process requires transportation of said first and second clones to a single 
computer of a plurality of computers of said computer network; 

transporting said first clone to said single computer; and 

forming, in a single computer, said second clone from said first clone. 



20. The method for implementing remote programming in a computer network as in Claim 19 further com- 
prising: 

transporting said first clone from said single computer to said first-mentioned place process; 

25 and 

transporting said second clone from said single computer to said second place process. 

21. A method for interprocess communication in a computer comprising the steps of: 

defining a plurality of object-oriented classes including an agent class; 
30 forming instructions for a computer process including said object-oriented classes, sub- 

classes of said object-oriented classes, and a meet operation; and 

interpreting said instructions on a processor in said computer network wherein, in response 
to said meet operation, a meeting place process provides a first agent process access to a second agent 
process and provides said second agent process access to said first agent process and further wherein 
35 said first and second agent processes are members of said agent class, 

22. The method for interprocess communication in a computer as in Claim 21 wherein said meeting place proc- 
ess is a member of a place class in said plurality of object-oriented classes and further wherein said first 
and second agent processes occupy said meeting place process. 

40 

23. The method for interprocess communication in a computer as in Claim 22 further comprising forming a 
second place process wherein: 

said second place process is a member of said place class; 
said second place process is a subplace of said meeting place process; and 
45 said meeting place is a superplace of said second place. 

24. A method for controlling movement of processes in a computer network, said method comprising the steps 
of: 

defining a plurality of object-oriented classes including an agent class, a place class, and a 

ticket class; 

forming a plurality of place processes in said computer network wherein each of said plur- 
ality of place process is a member of said place class; 

forming an agent process wherein said agent process is a member of said agent class and 
occupies a first place process in said plurality of place processes; and 

forming a ticket wherein said ticket is a member of said ticket class and defines a trip in- 
volving the movement of said agent process from said first place process to a second place process in 
said plurality of place processes. 
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25. A method for limiting capabilities of processes in a computer network, said method comprising: 

defining a plurality of object-oriented classes including a process class and a permit class; 
forming a process wherein said process is a member of said process class; and 
forming a permit wherein said permit is a member of said permit class and specifies one or 
5 more capabilities of said process. 

26. The method as in Claim 25 further comprising; 

defining within said process class a go operation; and 

specifying within said permit whether said process is capable of performing said go opera- 

10 tion. 

27. The method as in Claim 25 or 26 further comprising: 

defining within said process class a send operation; and 

specifying within said permit whether said process is capable of performing said send 

5 operation. 

28. The method as in Claim 25, 26 or 27 further comprising: 

defining within said process class a charge operation; and 

specifying within said permit whether said process is capable of performing said charge op- 
eration. 

20 

29. The method as in any one of Claims 25 to 28 further comprising: 

defining within said process class a terminate operation; and 

specifying within said permit whether said process is capable of performing said terminate 

operation. 

25 

30. The method as in any one of Claims 25 to 29 further comprising specifying within said permit whether 
said process is capable of creating a second process, different from said first-mentioned process, wherein 
said second process is a member of said process class. 

30 31. The method as in any one of Claims 25 to 30 further comprising: 
defining an object-oriented place class; and 

specifying within said permit whether said process is capable to creating members of said 

place class. 

35 32. The method as in any one of Claims 25 to 31 further comprising specifying within said permit whether 
said process is restarted upon failure of said process. 

33. The method as in any one of Claims 25 to 32 further comprising specifying within said permit an amount 
of processing that is allotted to said process. 
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34. The method as in any one of Claims 25 to 33 further comprising specifying within said permit a time at 
which said process is terminated. 



35. The method as in any one of Claims 25 to 34 further comprising: 

defining within said process class a restrict operation; 
45 forming instructions for a computer process, said instructions including said classes, sub- 

classes and of said classes, and said restrict operation; 

interpreting said instructions on a processor in said computer network wherein, in response 
to said restrict operation, a second permit, which is different from said first-mentioned permit, is formed 
and further wherein said second permit is a member of said permit class and specifies a group of one or 
more capabilities of said one or more capabilities of said process; and 

restricting said process to said group of one or more capabilities specified by said second 

permit. 

36. In a computer, a method of interpreting processes of various versions of an instruction set, said method 
55 comprising: 

defining a plurality of object-oriented classes including a class of classes and a class of cit- 
ations; 
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forming one or more class objects wherein said class objects are members of said class of 

classes; 

forming within a first of said class objects a citation wherein said citation specifies said first 
class object and specifies which of said class objects are backward compatible with said first class object. 

5 

37. In a computer network having a plurality of computers, a communication process comprising: 

providing a plurality of place processes within said computer network wherein each place 
process is a locale in one of said computers for zero or more agent processes; 

specifying, by a ticket means, a trip for an agent process to a destination place process in 
io said plurality of place processes; and 

transporting, in response to a send operation within said agent process, a clone of said agent 
process to said destination place process. 



15 



20 



25 



30 



38. In a computer network having a plurality of computers, the communication process as in Claim 37 further 
comprising specifying, by a second ticket means, a second trip, which is different from said first- 
mentioned trip, for said agent process to a second destination place process in said plurality of place proc- 
esses. 

39. In a computer network having a plurality of computers, the communication process as in Claim 37 further 
comprising: 

determining that said first-mentioned clone, in taking said first trip, and a second clone, in 
taking said second trip, are both to be transported to a single computer of said computers; 
moving to said single computer said first clone; and 

forming within said single computer said second clone from said first clone. 

. 40. In a computer network having a plurality of computers, the communication process as in Claim 39 further 
comprising transporting said first clone to said first-mentioned destination place process. 

41. In a computer network having a plurality of computers, the communication process as in Claim 39 further 
comprising transporting said second clone to said second destination place process. 

42. In a computer network having a plurality of computers, the communication process as in Claim 37further 
comprising transporting, in response to a go operation within said agent process, said agent process to 
said destination place process specified by said ticket means. 

35 43. In a computer network having a plurality of computers, the communication process as in Claim 37 further 
comprising specifying said destination place process by a name within said ticket means. 

44. In a computer network having a plurality of computers, the communication process as in Claim 37 further 
comprising specifying said destination place process by an address within said ticket means. 

40 

45. In a computer network having a plurality of computers, the communication process as in Claim 37further 
comprising specifying, within said ticket means, said destination place process by a citation of a class of 
which said destination place process is a member. 

46. In a computer network having a plurality of computers, the communication process as in Claim 37further 
comprising specifying, within said ticket means, said destination place process by any combination of an 
address of said destination place process, a name of said destination place process, and a citation of a 
class of which said destination place process is a member. 

47. In a computer network having a plurality of computers, the communication process as in Claim 37 further 
50 comprising specifying, within said ticket means, a transportation means wherein said transportation 

means specifies a type of intercomputer communications means by which said clone is transported. 

48. In a computer network having a plurality of computers, the communication process as in Claim 37 further 
comprising controlling, with a destination permit contained in said ticket means, a deadline for said agent 

55 process at said destination place process. 

49. In a computer network having a plurality of computers, the communication process as in Claim 37further 
comprising controlling, with a destination permit contained in said ticket means, operations that said agent 
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process is allowed to perform at said destination place process. 

50. In a computer network having a plurality of computers, the communication process as in Claim 37further 
comprising controlling, with a destination permit contained in said ticket means, resources that said agent 
process is allowed to consume at said destination place process. 

51. In a computer network having a plurality of computers, the communication process as in Claim 37further 
comprising specifying, with a destination permit contained in said ticket means, a priority for said agent 
process at said destination place process relative to other processes at said destination place process. 

52. In a computer network having a plurality of computers, the communication process as in Claim 37f urther 
comprising controlling, via a permit means, a capability that a process is allowed to have. 

53. In a computer network having a plurality of computers, the communication process as in Claim 52wherein 
said capability comprises a priority for said process relative to other processes. 

75 

54. In a computer network having a plurality of computers, the communication process as in Claim 37 wherein 
said agent process owns an object. 

55. In a computer network having a plurality of computers, the communication process as in Claim 53 wherein 
20 said step of transporting a clone of said agent process comprises transporting a copy of said object. 

56. In a computer network having a plurality of computers, the communication process as in Claim 55 further 
comprising interchanging for said copy a second object at said destination place process wherein said 
second object has a digest equivalent to said first-mentioned digest and further wherein said copy is not 

25 transported to said destination place process. 

57. In a computer network having a plurality of computers, the communication process as in Claim 54 further 
comprising the step using an interchanged object for said object at said destination place process thereby 
eliminating the need to transport said object to said destination place process. 

30 

58. In a computer network having a plurality of computers, the communication process as in Claim 37 wherein 
said transporting step further comprises a step of entering said destination place process. 

59. In a computer network having a plurality of computers, the communication process as in Claim 37 wherein 
said transporting step further comprises a step of exiting said source place process. 

60. In a computer network having a plurality of computers, the communication process as in Claim 37 wherein 
said destination place process is a meeting place process and said meeting place arranges a meeting 
between a requestor agent process and a petitioned agent process. 

40 61. In a computer, a communication process comprising: 

providing a first agent process and a second agent process; 

specifying a meeting between said first and second agent processes by a petition means; 

and 

arranging said meeting between said first and second agent processes as defined by said 

45 petition. 

62. In a computer, the communication process as in Claim 61 further comprising forming said petition means 
within said first agent process. 
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63. In a computer, the communication process as in Claim 61 or 62 wherein said step of specifying a meeting 
comprises specifying within said petition means said second agent process. 

64. In a computer, the communication process as in Claim 63 wherein said step of specifying said second 
agent process comprises specifying, within said petition means, said second agent by a name. 

55 65. In a computer, the communication process as in Claim 63, wherein said step of specifying said second 
agent process comprises specifying, within said petition means, a class of which said second agent proc- 
ess is a member. 
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66. In a computer, the communication process as in Claim 63 wherein said step of specifying said second 
agent process comprises specifying, within said petition means, a citation of a class of which said second 
agent process is a member. 

67. In a computer, the communication process as in Claim 61 wherein said step of specifying a meeting com- 
prises specifying, within said petition means, a maximum time period for arranging said meeting. 

68. In a computer, the communication process as in Claim 61 wherein said step of arranging said meeting 
comprises providing to said first agent process a reference to said second agent process. 

69. In a computer, the communication process as in Claim 68 wherein said step of arranging said meeting 
further comprises providing to said second agent process a reference to said first agent process. 

70. In a computer, the communication process as in Claim 81 further comprising causing, in response to an 
instruction within said first agent process, performance of an operation within said second agent process. 

71. In a computer, the communication process as in Claim 70 wherein said first or second agent process owns 
an object. 

72. In a computer, the communication process as in Claim 71 further comprising providing to said second or 
20 to said first agent process respectively a reference to said object, or a reference to a copy of said object. 

73. In a computer, the communication process as in Claim 72 wherein said reference is a protected reference. 

74. In a computer network having a plurality of computers, a communication system comprising: 
25 an agent means having a ticket means and a send operation; and 

a plurality of place means wherein each place means is operable in one of said plurality of 

computers; 

wherein said agent means is at a first place means in said plurality of place means; 
said ticket means specifies a trip to said agent means to a destination place means 
30 in said plurality of place means; and 

said send operation transports a clone of said agent means to said destination place 

means. 
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75. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said agent means further comprises a second ticket means, different from said first-mentioned ticket 
means, that specifies a second trip to a second destination place means for said agent means. 

76. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
performance of said send operation transports a second clone of said agent means to said second des- 
tination place means. 



77. In a computer network having a plurality of computers, the communication system as in Claim 76 wherein: 
said first-mentioned trip and said second trip both include transportation to a single com- 
puter in said plurality of computer; and 

further wherein, in transpor; :g said first-mentioned clone to said first-mentioned destina- 
45 tion place means and said second clone to said second destination place means, performance of said 

send operation: 

(a) transports said first clone to said single computer and 

(b) forms said second clone from said first clone within said single computer. 

so 78. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said agent means further comprises a go operation wherein said go operation transports said agent 
means to a third destination place means specified by a third ticket means. 

79. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
55 said ticket means further comprises a name which identifies said destination place means. 

80. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises an address for said destination place means. 
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81. In a computer network having a plurality of computers, the communication process as in Claim 44 or the 
system as in Claim 80 wherein said address is a teleaddress. 

82. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises a citation means which specifies a class of which said destination 
place means is a member. 

83. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises any combination selecting from the group consisting of an address 
of said destination place means, a name of said destination place means, and a citation means which 
specifies a class of which said destination place means is a member. 

84. In a computer network having a plurality of computers, the communication system as in Claim 74 or proc- 
ess of Claim 37 wherein said ticket means further comprises means for specifying a maximum time period 
for said trip. 

85. In a computer network having a plurality of computers, the communication system as in Claim 74 or a 
process of Claim 37 wherein said ticket means further comprises means for specifying a desired time 
period for said trip. 

20 86. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises a way means for specifying a type of intercomputer communications 
means by which said trip is to be accomplished. 

87. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
25 said ticket means further comprises a permit means for controlling a deadline for said agent means at 

said destination place means. 

88. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises a permit means for controlling operations that said agent means is 

30 allowed to perform at said destination place means. 

89. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises a permit means for controlling resources that said agent means is 
allowed to consume at said destination place means. 

35 

90. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said ticket means further comprises a permit means for specifying a priority for said agent means at said 
destination place means relative to other agent means at said destination place means. 

91. In a computer network having a plurality of computers, the communication system as in Claim 74 further 
40 comprising a permit means for controlling a capability that an a*. : means is allowed to have. 

92. In a computer network having a plurality of computers, the communication system as in Claim 91 or the 
process as in Claim 52 wherein said permit means is a native permit. 

45 9 3. In a computer network having a plurality of computers, the communication system as in Claim 91 or the 
process as in Claim 52 wherein said permit means is a local permit. 

94. In a computer network having a plurality of computers, the communication system as in Claim 91 or the 
process as in Claim 52 wherein said permit means is a temporary permit. 
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95. In a computer network having a plurality of computers, the communication system as in Claim 91 or the 
process as in Claim 52 wherein said capability comprises resources that said agent means of Claim 91 
or said process of Claim 52 respectively can consume. 

96. In a computer network having a plurality of computers, the communication system as in Claim 91 or the 
process as in Claim 52 wherein said capability comprises a deadline after which the agent means of Claim 
91 or the process of Claim 52 respectively cannot proceed. 
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97. In a computer network having a plurality of computers, the communication system as in Claim 91 further 
comprising other agent means wherein said capability comprises a priority for said agent means relative 
to said other agent means. 

98. In a computer network having a plurality of computers, the communication system as in Claim 91 or the 
process of Claim 52 wherein said capability comprises permission for said agent means or said process 
respectively to perform selected operations. 

99. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said agent means owns an object. 

100. In a computer network having a plurality of computers, the communication system as in Claim 99 or the 
process of Claim 54 wherein said object has a digest. 

1 01. In a computer network having a plurality of computers, the communication system as in Claim 1 00 wherein 
a copy of said object is transported with said clone by performance of said send operation. 

102. In a computer network having a plurality of computers, the communication system as in Claim 101 wherein- 
a second object at said destination place means is interchanged for said copy; and 

further wherein said second object has a digest equivalent to said first-mentioned digest, 
thereby obviating transportation of said copy to said destination place means. 

103. In a computer network having a plurality of computers, the communication system as in Claim 101 wherein 
said send operation uses an interchanged object for said copy at said destination place means thereby 
eliminating the need to transport said copy of said object to said destination place means. 

1 04. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said place means further comprises means for entering said place means. 

1 05. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said place means further comprises means for exiting said place means. 

1 06. In a computer network having a plurality of computers, the communication system as in Claim 74 wherein 
said place means further comprises meeting place means wherein said meeting place means arranges 
a meeting between a requestor agent means and a responder agent means. 

107. In a computer, a communication system comprising: 

meeting place means having a meet operation wherein said meeting place is a locale for a 
plurality of agent means; 

a petition means; 

a first agent means in said plurality of agent means; and 

a second agent means in said plurality of agent means wherein; 

said first and second agent means can meet with any of said plurality of agent means; 

said petition means specifies a meeting between said first and second agent means; 

and 

in response to said meet operation, said meeting place means arranges said meeting. 

108. In a computer, the communication system as claimed in Claim 107 formed by a process according to any 
one of claims 61 to 73. 

109. In a computer, the communication system as in Claim 79 or 108 or the communication process as in Claim 
43 or 64 wherein said name is a telename. 

110. In a computer, the communication system as in Claim 107 further wherein said meet operation provides 
to said first agent means a reference to said second agent. 

111. In a computer, the communication system as in Claim 110 further wherein said meet operation provides 
to said second agent means a reference to said first agent means. 

112. In a computer, the communication system as in Claim 107 further wherein said first agent means can 
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cause performance of an operation within said second agent means. 

113. In a computer, the communication system as in Claim 112 wherein at least one of said first agent means 
or said second agent means owns an agent. 

114. In a computer, the communication system as in Claim 1 1 3 further wherein said first or second agent means 
can provide to said second or first agent means respectively a reference to said object or to a copy of 
said object. 

115. In a computer, the communication system as in Claim 114 wherein said reference is a protected reference. 

116. In a computer network having one or more computers, a method for transferring data from a first engine 
process to a second engine process, said method comprising the steps of: 

(a) providing means for executing one or more agent processes wherein said executing means com- 
prises said first and second engine processes and further wherein each said agent process comprises 
instructions from a computer instruction set and has an execution state; 

(b) providing within said computer instruction set a go instruction wherein said go instruction is con- 
tained within a first agent process executing within said first engine process and further wherein per- 
formance of said go instruction causes: 

(i) suspension of execution of said first agent process by said first engine process; 

(ii) representation of said first agent process such that said execution state of said first agent proc- 
ess is preserved; 

(iii) transfer of said representation of said first agent process from said first engine process to said 
second engine process; and 

(iv) resumption of execution of said first agent process by said second engine process; 

(c) causing execution of said agent process by said first engine process, thereby causing performance 
of said go instruction. 

117. The method of Claim 116 wherein said computer instruction set is object-oriented. 

30 118. The method of Claim 117 wherein said plurality of agent processes are objects of said object-oriented 
computer instruction set. 

119. The method of Claim 116 further comprising the step of adding data to said first agent process prior to. 
causing performance of said go instruction; 

35 wherein said representation of said first agent process includes said data; and 

further wherein transfer of said representation of said first agent process to said second en- 
gine process includes transfer of said data. 

120. The method of Claim 116 wherein said first agent process comprises data representing a message to be 
40 transported from said first engine process to said second engine process; and 

further wherein transfer of said first agent process resulting from execution of said go in- 
struction causes transfer of said data from said first engine process to said second engine process. 

121. The method of Claim 116 wherein said first engine process executes on a first computer and said second 
engine process executes on a second computer wherein said first and second computers are part of said 
computer network. 

122. A method for transferring data from a first engine process to one or more engine processes, said method 
comprising the steps of: 

(a) providing means for executing a plurality of agent processes which comprise instructions from a 
50 computer instruction set wherein said agent process execution means comprises said first and one or 

more engine processes and further wherein each said agent process has an execution state; 

(b) providing within said computer instruction set a send instruction wherein said send instruction is 
contained within a first agent process in said plurality of agent processes and further wherein, execution 
of said send instruction, includes the steps of; 

55 (i) forming one or more copies of said first agent process wherein said copies preserve and include 

said execution state of said first agent process; 

(ii) transferring each of said copies of said first agent process from said first engine process to a 
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respective one of said one or more engine processes; and 

(iii) effectuating execution of each of said copies of said first agent process by said respective one 
of said one or more engine processes so as to simulate the resumed execution of said first agent 
process. 

1 23. The method of Claim 1 22 wherein, upon a condition wherein two or more of said copies of said first agent 
process are to be transferred from said first engine process to a single second engine process, the transfer 
of said two or more copies of said first agent process comprises the steps of: 

transferring to said second engine process a single copy of said first agent process; and 
forming within said second engine process from said single copy said two or more copies 
of said first agent process. 

124. A method of transferring data from a first agent process which is executing within a computer system to 
a second agent process which is executing within said computer system wherein said first and second 
agent processes are occupants of a place process, said method comprising the steps of: 

causing, in response to a meet instruction issued by said first agent process, execution of 
a procedure by said second agent process wherein said procedure is a portion of said second agent proc- 
ess and comprises a collection of computer instructions contained within said second agent computer 
process; and 

providing to said first agent process, in response to a second instruction which is issued by 
said second agent process and which is part of said procedure, means for accessing said second agent 
process. 

125. The method of Claim 124 wherein said step of causing execution of a procedure by said second agent 
process comprises: 

causing, in response to said meet instruction issued by said first agent process, execution 
of a second procedure by said place process wherein execution of said second procedure by said place 
process issues an instruction which causes said second agent process to execute said first-mentioned 
procedure. 

126. The method of Claim 124 wherein said means for accessing said second agent process is provided to 
said first agent process by said place process. 

127. The method of Claim 126 wherein, at approximately the time said place process provides to said first agent 
process said means for accessing said second agent process, said place process provides to said second 
agent process means for accessing said first agent process. 

128. A method for transferring a first computer process from a first computer system to a second computer 
system, said first computer system comprising a first CPU and a first memory and said second computer 
system comprising a second CPU and a second memory, said method comprising: 

initiating execution of said first computer process within said first CPU wherein said com- 
puter process has an execution state; 

suspending execution of said first computer process within said first CPU; 

representing said first computer process as data in said first memory wherein said data in- 
cludes said execution state of said first computer process at the time execution of said first computer proc- 
ess is suspended; 

transferring said data from said first memory to said second memory; 

forming a second computer process on said second computer system from said data wherein 
said second computer process has said state of execution represented in said data; and 

causing execution of said second computer process, thereby effectively simulating resump- 
tion of execution of said first computer process within said second CPU. 
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